Re: [Qemu-devel] [PATCH v2] linux-user: Fix 32-on-64 mmap for x86_64
On 21.12.2011, at 03:43, 陳韋任 wrote: This patch is actually wrong and we should rather make proper -R values the default instead of relying on MAP_32BIT. >>> >>> I don't understand what "make proper -R values" means. Where/how we can >>> apply >>> "-R"? >> >> Please see my other mail about this: >> >> http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg01697.html > > Ah, "-R" should mean > >-R size reserve size bytes for guest virtual address space Yes, that's what I was referring to :) Alex
Re: [Qemu-devel] [PATCH v2] linux-user: Fix 32-on-64 mmap for x86_64
> >> This patch is actually wrong and we should rather make proper -R values > >> the default instead of relying on MAP_32BIT. > > > > I don't understand what "make proper -R values" means. Where/how we can > > apply > > "-R"? > > Please see my other mail about this: > > http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg01697.html Ah, "-R" should mean -R size reserve size bytes for guest virtual address space right? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH v2] linux-user: Fix 32-on-64 mmap for x86_64
On 20.12.2011, at 08:46, 陳韋任 wrote: >> This patch is actually wrong and we should rather make proper -R values the >> default instead of relying on MAP_32BIT. > > I don't understand what "make proper -R values" means. Where/how we can apply > "-R"? Please see my other mail about this: http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg01697.html Alex
Re: [Qemu-devel] [PATCH v2] linux-user: Fix 32-on-64 mmap for x86_64
> This patch is actually wrong and we should rather make proper -R values the > default instead of relying on MAP_32BIT. I don't understand what "make proper -R values" means. Where/how we can apply "-R"? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH v2] linux-user: Fix 32-on-64 mmap for x86_64
On 25.11.2011, at 14:06, Peter Maydell wrote: > On 24 November 2011 23:43, Alexander Graf wrote: >> --- >> >> v1 -> v2: >> >> - make prettier by just wrapping mmap in linux-user/mmap.c > > Hmm. I prefer the non-wrapped version :-) > In particular, qemu_mmap() implies that (like other qemu_foo > wrappers) this is a portability wrapper that should be used for > all mmap calls. But actually we only want to apply MAP_32BIT > for those mmap()s which are mmapping guest memory requests. > So just having an extra flag in the cases where we need the > flag seems more straightforward. > > I'd prefer a > > #if defined(MAP_32BIT) && defined(__x86_64__) && (TARGET_LONG_BITS == 32) > #define QEMU_MAP_32BIT MAP_32BIT > #else > #define QEMU_MAP_32BIT 0 > #endif > > and then use QEMU_MAP_32BIT. (That way it's obvious when you're > looking at the mmap() calls that they're not using the host's > MAP_32BIT but something that might be different.) This patch is actually wrong and we should rather make proper -R values the default instead of relying on MAP_32BIT. Alex
Re: [Qemu-devel] [PATCH v2] linux-user: Fix 32-on-64 mmap for x86_64
On 24 November 2011 23:43, Alexander Graf wrote: > --- > > v1 -> v2: > > - make prettier by just wrapping mmap in linux-user/mmap.c Hmm. I prefer the non-wrapped version :-) In particular, qemu_mmap() implies that (like other qemu_foo wrappers) this is a portability wrapper that should be used for all mmap calls. But actually we only want to apply MAP_32BIT for those mmap()s which are mmapping guest memory requests. So just having an extra flag in the cases where we need the flag seems more straightforward. I'd prefer a #if defined(MAP_32BIT) && defined(__x86_64__) && (TARGET_LONG_BITS == 32) #define QEMU_MAP_32BIT MAP_32BIT #else #define QEMU_MAP_32BIT 0 #endif and then use QEMU_MAP_32BIT. (That way it's obvious when you're looking at the mmap() calls that they're not using the host's MAP_32BIT but something that might be different.) -- PMM
