Re: [Qemu-devel] How to measure guest memory access (qemu_ld/qemu_st) time?

[Lluís Vilanova]

Blue Swirl writes:

> On Mon, Jun 18, 2012 at 8:28 AM, 陳韋任 (Wei-Ren Chen)
> <address@hidden> 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.


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