[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: |
Tue, 22 Mar 2016 15:02:29 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Stefan Hajnoczi writes:
> On Wed, Mar 16, 2016 at 03:10:01PM +0000, Peter Maydell wrote:
>> On 2 March 2016 at 10:55, Stefan Hajnoczi <address@hidden> wrote:
>> > On Tue, Feb 23, 2016 at 07:22:07PM +0100, Lluís Vilanova wrote:
>> >> NOTE: This series applies on top of "trace: Show vCPU info in guest code
>> >> events"
>> >>
>> >> This series adds to new events:
>> >>
>> >> * guest_vmem: memory accesses performed by vCPUs (guest code)
>> >>
>> >> * guest_vmem_user_syscall: memory accesses performed by syscall emulation
>> >> when
>> >> running QEMU in user-mode.
>> >>
>> >> Signed-off-by: Lluís Vilanova <address@hidden>
>> >> ---
>> >>
>> >> Lluís Vilanova (5):
>> >> exec: [tcg] Track which vCPU is performing translation and execution
>> >> trace: [all] Add "guest_vmem" event
>> >> user: Refactor lock_user body into do_lock_user
>> >> user: Set current vCPU during syscall execution
>> >> trace: [all] Add "guest_vmem_user_syscall" event
>>
>> > Any comments from TCG folks?
>>
>> 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).
So, while it's not the perfect place to do it, I think it's the best one we have
now. Having calls to both lock_user and trace_guest_vmem_user_syscall in syscall
emulation code should be avoided to keep the code cleaner.
Thanks,
Lluis