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 <stefa...@gmail.com> 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 <vilan...@ac.upc.edu> >> >> --- >> >> >> >> 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
