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: Lluís Vilanova
Subject: Re: [Qemu-devel] How to measure guest memory access (qemu_ld/qemu_st) time?
Date: Tue, 19 Jun 2012 13:51:15 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Michael Kang writes:

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



reply via email to

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