On Tue, 7 Mar 2023 at 10:12, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Mon, 6 Mar 2023 at 21:24, Richard Henderson > <richard.hender...@linaro.org> wrote: > > > > On 3/6/23 04:56, Peter Maydell wrote: > > > On Mon, 6 Mar 2023 at 02:14, Richard Henderson > > > <richard.hender...@linaro.org> wrote: > > >> > > >> Zero is the value for 'off', and should not be used with -R. > > >> We have been enforcing host page alignment for the non-R > > >> fallback of MAX_RESERVED_VA, but failing to enforce for -R. > > > > > > I'm pretty sure we have users who specifically use "-R 0" to > > > ask for "definitely turn off any reserved VA". > > > Here's a random example from an old gcc bug report: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60681 > > > and somebody using it via the environment variable: > > > https://www.openembedded.org/pipermail/openembedded-core/2015-January/100572.html > > > > Odd. > > > > Well, it won't actually have the effect of "definitely turn off", it will > > merely leave > > things as per the default, which *will* enable reserved va for 32-bit > > guests on 64-bit hosts. > > > > The only remaining question is whether we diagnose this oddness or silently > > accept it. It > > feels like someone playing with options they don't actually understand and > > an error is > > warranted. > > I'm pretty sure I've issued the advice "turn off the reserved > area stuff with -R 0" in the past, for working around various > QEMU bugs where it wasn't able to allocate the whole reserved > area it wanted to but the guest program didn't actually care.
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. thanks -- PMM
