| Message ID | 285BCAC5-E270-4B49-9DC5-081A79691BE3@suse.de |
|---|---|
| State | New |
| Headers | show |
> >> IIRC mmap'ing files would break with 32-on-64, but I'd have to check up > >> on the details. I ended up passing MAP_32BIT to all linux-user mmap > >> calla for 32-on-x86_64, but that doesn't work with -R. > > > > Hmm, I thought we'd fixed that. It's the reason h2g_valid exists. > > > > Either way it should definitely work with -R. I specifically added that > > to avoid problems with the host mmap picking inconvenient addresse. > > > > MAP_32BIT is an unconsionable hack, and doesn't exist on other 64-bit > > hosts. > > Yes, I agree. I just sat down once more and checked if I could get it > working with -R and everything seems fine so far. > > Is there any particular reason we're not reserving all of the possible 32 > bit address space for 32-on-64 guests? The way it's today with the default > being completely broken and -R fixing everything if you give it a large > enough value is ... suboptimal. -R doesn't actually fix everything :-) In particular if you use ulimit -v then there's a good chance it will break completely. Having said that, it's not hard to check ulimit -v first. I still think the current config should work. The automagical guest_base isn't quite as reliable as -R (the guest and host spaces probably overlap) but it should be comparable to 32-on-32. If we do default to -R 4G for 32-on-64, then there's a good argument for enabling it by default for all combinations. For 32-bit hosts you can either try to guess the size of the host user address space, or just start by trying 3G and if that doesn't work progressively fall back to 2G, 1G, then current behavior. For 64-on-64 maybe pick a large value, remebering that the reservation probably isn't completely free. Paul
On 14 December 2011 01:43, Alexander Graf <agraf@suse.de> wrote:
> +unsigned long reserved_va = 0xf7000000;
So why 0xf7000000 rather than the whole of the 32 bit space?
(In particular for ARM targets we want to be able to mmap
at 0xFFFFxxxx...)
-- PMM
On 20.12.2011, at 17:17, Peter Maydell wrote: > On 14 December 2011 01:43, Alexander Graf <agraf@suse.de> wrote: >> +unsigned long reserved_va = 0xf7000000; > > So why 0xf7000000 rather than the whole of the 32 bit space? > > (In particular for ARM targets we want to be able to mmap > at 0xFFFFxxxx...) Because that didn't work for me. We still need the commpage above our reserved memory range, so this was the highest value that was safe for me. Alex
On 20 December 2011 16:29, Alexander Graf <agraf@suse.de> wrote: > On 20.12.2011, at 17:17, Peter Maydell wrote: >> On 14 December 2011 01:43, Alexander Graf <agraf@suse.de> wrote: >>> +unsigned long reserved_va = 0xf7000000; >> >> So why 0xf7000000 rather than the whole of the 32 bit space? >> >> (In particular for ARM targets we want to be able to mmap >> at 0xFFFFxxxx...) > > Because that didn't work for me. We still need the commpage > above our reserved memory range, so this was the highest value > that was safe for me. Hmm, that suggests we didn't get the interaction of the commpage with the reserved range right -- the commpage is part of the guest memory space so it should be OK for it to be inside the reserved range. -- PMM
On 20.12.2011, at 17:33, Peter Maydell wrote: > On 20 December 2011 16:29, Alexander Graf <agraf@suse.de> wrote: >> On 20.12.2011, at 17:17, Peter Maydell wrote: >>> On 14 December 2011 01:43, Alexander Graf <agraf@suse.de> wrote: >>>> +unsigned long reserved_va = 0xf7000000; >>> >>> So why 0xf7000000 rather than the whole of the 32 bit space? >>> >>> (In particular for ARM targets we want to be able to mmap >>> at 0xFFFFxxxx...) >> >> Because that didn't work for me. We still need the commpage >> above our reserved memory range, so this was the highest value >> that was safe for me. > > Hmm, that suggests we didn't get the interaction of the commpage > with the reserved range right -- the commpage is part of the > guest memory space so it should be OK for it to be inside > the reserved range. That is very likely. Right now we take the reserved range and then put the commpage above it, not guaranteeing that nothing is there. I don't see what other way to do it if we want to be able to reserve less than all 32 bits of virtual address space (which might not be available!) Alex
diff --git a/linux-user/main.c b/linux-user/main.c index 788ff98..3ffee40 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -48,8 +48,19 @@ unsigned long mmap_min_addr; #if defined(CONFIG_USE_GUEST_BASE) unsigned long guest_base; int have_guest_base; +#if (TARGET_LONG_BITS == 32) && (HOST_LONG_BITS == 64) +/* + * When running 32-on-64 we should make sure we can fit all of the possible + * guest address space into a contiguous chunk of virtual host memory. + * + * This way we will never overlap with our own libraries or binaries or stack + * or anything else that QEMU maps. + */ +unsigned long reserved_va = 0xf7000000; +#else unsigned long reserved_va; #endif +#endif static void usage(void); extern int use_stopflag;