On Fri, 17 Mar 2023 at 14:57, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Fri, 17 Mar 2023 at 14:46, Richard Henderson > <richard.hender...@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
