On Tue, Jun 19, 2012 at 4:26 AM, Lluís Vilanova <vilan...@ac.upc.edu> wrote: > Blue Swirl writes: > >> On Mon, Jun 18, 2012 at 8:28 AM, 陳韋任 (Wei-Ren Chen) >> <che...@iis.sinica.edu.tw> wrote: >>>> The reason why we want to do the measuring is we want to use KVM (sounds >>>> crazy >>>> idea) MMU virtualization to speedup the guest -> host memory address >>>> translation. >>>> I talked to some people on LinuxCon Japan, included Paolo, about this >>>> idea. The >>>> feedback I got is we can only use shadow page table rather than EPT/NPT to >>>> do >>>> the address translation (if possible!) since different ISA (ARM and x86, >>>> for >>>> example) have different page table format. Besides, QEMU has to use ioctl >>>> to ask >>>> KVM to get the translation result, but it's an overkill as the ARM page >>>> table >>>> is quite simple, which can be done in user mode very fast. >>> >>> Anyone would like to give a comment on this? ;) >>> >>> From the talk with Laurent on #qemu, he said the way he thought of is >>> translating GVA -> GPA manually (through software), then try to insert >>> GPA -> HPA into EPT, that's the only way HW can help. > >> For some 32 bit guests on some 64 bit hosts, maybe KVM could indeed >> help. Just map the whole 4G guest virtual address space so that guest >> memory accesses can be turned 1:1 into raw direct accesses. I/O pages >> would be unmapped, accesses handled via fault path. > > But if QEMU/TCG is doing a GVA->GPA translation as Wei-Ren said, I don't see > how > KVM can help. > > 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. Thanks MK > > > 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 > -- www.skyeye.org