qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] About address mapping between host and guest in QEMU


From: Brendan Dolan-Gavitt
Subject: Re: [Qemu-devel] About address mapping between host and guest in QEMU
Date: Fri, 24 Apr 2015 15:50:41 -0400

One possible option that has come up in the past is disabling the TLB
for your testing. It is slower, though, and would only work on TCG,
not KVM.

The way I'm currently doing this is by changing the conditional jump
here to an absolute one inside of the TCG code generator for i386 (and
of course you can do something similar on other archs). The code here
has changed since I last looked at it, but this is roughly the place
to look:

https://github.com/qemu/qemu/blob/master/tcg/i386/tcg-target.c#L1222

Depending on your needs, you might want to also look at (shameless
plug) PANDA [1], which provides callbacks and a plugin architecture
for many things that happen in QEMU, including memory accesses. You
can see how we implement the memory callback here:

https://github.com/moyix/panda/blob/master/qemu/tcg/i386/tcg-target.c#L1079

Cheers,
Brendan

[1] https://github.com/moyix/panda

On Fri, Apr 24, 2015 at 3:09 PM, Christopher Covington
<address@hidden> wrote:
> On 04/24/2015 08:46 AM, Peter Maydell wrote:
>> On 24 April 2015 at 12:26, Paolo Bonzini <address@hidden> wrote:
>>> On 24/04/2015 04:10, Wenjie Liu wrote:
>>>> The thing I am trying to achieve is to get the data and guest physical
>>>> address of every guest memory access, so I need to known which API can
>>>> be used to do the address transform.
>>>
>>> The short answer is that is difficult, because most guest memory
>>> accesses do not call any C function.  QEMU has a virtual TLB; if you
>>> have a TLB hit, the code generated by the JIT compiler does the conversion.
>>
>> In fact on a TLB hit it's possible that it's not actually any
>> longer determinable what the guest physical address was. This
>> only really happens with buggy guests, but if the guest does
>> a load that brings an entry into the TLB and then rewrites the
>> page table but fails to do the TLB maintenance operation, then
>> at the point when a subsequent load hits in the TLB we know
>> the guest virtual address and the host virtual address but not
>> the guest physical address, and we can't find the guest physaddr
>> any more even if we walk the page tables, because those have
>> been changed...
>>
>> Wanting to do this kind of memory access tracing is a pretty
>> common user request, though, and it would be nice if QEMU
>> had the facilities for it. It's just that our current design
>> is really not set up to make it easy to implement.
>
> While probably very slow, could the kind of guest memory trace in question be
> captured using the GDB stub and a breakpoint on every load an store
> instruction (or alternatively, a watchpoint on every possible address)?
>
> Chris
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>



reply via email to

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