Michael Kang writes: > On Tue, Jun 19, 2012 at 4:26 AM, Lluís Vilanova <vilan...@ac.upc.edu> wrote: [...] >> I could understand having multiple 32bit regions in QEMU's virtual space (no >> need for KVM), one per guest page table, and then simply adding an offset to >> every memory access to redirect it to the appropriate 32-bit region (1 region >> per guest page table). >> >> This could translate a single guest ld/st into a host ld+add+ld/st (the first >> load is to get the "region" offset for the currently executing guest >> context). >> >> With this, you can use 'mprotect' in QEMU to enforce the guest's page >> permissions (as long as the host supports it), and 'mmap' to share the host >> physical memory between the different 32-bit regions whenever the guest page >> tables share guest physical memory (again, as long as the host supports it). >> >> But I suppose having a guest with as many or more bits than the host is the >> common case, which hinders its applicability.
> I ever have some thought like you. Firstly , we only simulate 32bit > guest on 64 bit host for the case. > Secondly I ever did some experiments. And I can not mmap the address > space more than > about 8G on 64 bit linux OS. Maybe there some limits in the linux > kernel of host. You can see your resource limits with "ulimit -a", but without more info I cannot tell what's actually going on. Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
