Re: [Qemu-devel] [PATCH 0/5] trace: Add events for vCPU memory accesses

[Lluís Vilanova]

Peter Maydell writes:

> On 22 March 2016 at 14:02, Lluís Vilanova <address@hidden> wrote:
>> Stefan Hajnoczi writes:
>> 
>>> On Wed, Mar 16, 2016 at 03:10:01PM +0000, Peter Maydell wrote:
>>>> The first two patches which add TCG guest data access tracing look
>>>> OK to me, but I'm much less sure about the last three which are
>>>> adding tracing into linux-user syscall emulation. I'm not sure
>>>> that lock_user is the right place to put that tracepoint.
>> 
>>> Any thoughts on this, Lluís?
>> 
>> Mmmm, I was struggling to find a place to easily add the tracing events
>> whenever the syscall emulation code accesses guest memory.
>> 
>> The lock_user function is used precisely for that, but it can be a bit
>> heavy-handed as to what memory is actually read/written, since it only marks 
>> the
>> "potential" ability of doing so (it's a sort of acquire/release interface 
>> that
>> differentiates between read and write acquires).

> Well, that's why I'm not certain about it. I would prefer us to
> not trace the accesses rather than put a trace in a wrong
> position.

Theoretically, that's what DEBUG_REMAP is for. A temporary host buffer is
allocated and data is copied in/out of it according to 'type'
(VERIFY_READ/VERIFY_WRITE) and 'copy'; so if the lock_user/unlock_user calls are
incorrect, QEMU will not read/write the correct guest memory values for syscall
emulation.

I used the logic when DEBUG_REMAP is used to understand when guest memory is
declared to be read/written. So the current approach for tracing is never in a
wrong position.

The only problem I see is that the syscall emulation code can declare it wants
read & write access to some guest memory while a real system would only do one
of the two (or even none). Tracing this is not incorrect either, since it's just
how QEMU is emulating that syscall, but it could be sub-optimal compared to a
real syscall implementation.


Cheers,
  Lluis