qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/9] linux-user: Diagnose incorrect -R size


From: Peter Maydell
Subject: Re: [PATCH 1/9] linux-user: Diagnose incorrect -R size
Date: Fri, 17 Mar 2023 15:05:26 +0000

On Fri, 17 Mar 2023 at 14:57, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Fri, 17 Mar 2023 at 14:46, Richard Henderson
> <richard.henderson@linaro.org> wrote:
> >
> > On 3/7/23 02:17, Peter Maydell wrote:
> > > It looks like we (inadvertently) broke "-R 0 means turn off"
> > > in 2019 with commit dc18baaef36d95e5; prior to that the
> > > 64-on-32 default was set by the initial value of the global
> > > variable and could be overridden on the command line. After
> > > that we ended up doing the default-value stuff after the
> > > command line was parsed instead.
> >
> > (Not 64-on-32, but 32-on-64.)
> >
> > I don't understand how 32-on-64 would ever work without reserved_va.  The 
> > host kernel
> > would otherwise place mmap blocks anywhere it chooses, which may not be 
> > within 4GB of any
> > given guest_base.
>
> I think most of the use cases weren't doing mmap of any
> kind. The gcc test suite is one example of that.

...but in any case, looking at the linux-user/mmap.c
code it doesn't let the kernel give it any old host
address, even in the no-reserved_va code path:
mmap_find_vma() calls mmap() with a hint address it wants
the kernel to try, and it refuses to use addresses which
aren't reachable by the guest (as defined by h2g_valid()).
So as long as the guest program isn't a really heavy
mmap user it will be fine even with a 0 reserved_va.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]