qemu-devel
[Top][All Lists]
Advanced

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

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


From: Lluís Vilanova
Subject: Re: [Qemu-devel] [PATCH 0/5] trace: Add events for vCPU memory accesses
Date: Wed, 23 Mar 2016 15:08:01 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Peter Maydell writes:

> On 22 March 2016 at 19:23, Lluís Vilanova <address@hidden> wrote:
>> Peter Maydell writes:
>>> 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.

> Also we sometimes lock an entire buffer but then don't read or write
> all of it. And a few places call g2h() directly and accesses via
> those code paths won't get traced.

> But really, an access to implement a syscall isn't a guest memory
> access, it's part of the implementation of the emulated kernel ABIs.
> We have tracing for that, it's the strace code (though the strace
> code is really very poor currently).

> Tracing memory accesses made by the emulated CPU makes total sense;
> but I think "what tracing should we do for linux-user code" is
> a separate question.

I see; I wasn't aware of strace support in QEMU. Maybe tracing that is going to
be an easier alternative if there is no clear way to express "guest memory
accesses from emulated syscalls".

We could just have a very simple pair of events:

  syscallN_pre(uint64_t num, uint64_t arg1, ..., uint64_t argN)
  syscallN_post(uint64_t num, uint64_t res, uint64_t arg1, ..., uint64_t argN)

hooked into the calls to strace.


Cheers,
  Lluis



reply via email to

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