qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael.Kang
Subject: Re: [Qemu-devel] How to measure guest memory access (qemu_ld/qemu_st) time?
Date: Tue, 19 Jun 2012 17:47:21 +0800

On Tue, Jun 19, 2012 at 4:26 AM, Lluís Vilanova <address@hidden> wrote:
> 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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]