Peter Maydell writes: > On 22 March 2016 at 14:02, Lluís Vilanova <vilan...@ac.upc.edu> 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
