Re: [Qemu-devel] [PATCH v8 0/5] hypertrace: Lightweight guest-to-QEMU trace channel

[Stefan Hajnoczi]

On Fri, Aug 04, 2017 at 09:32:25PM +0300, Lluís Vilanova wrote:
> Stefan Hajnoczi writes:
> 
> > On Sun, Jul 30, 2017 at 05:08:18PM +0300, Lluís Vilanova wrote:
> >> The hypertrace channel allows guest code to emit events in QEMU (the host) 
> >> using
> >> its tracing infrastructure (see "docs/trace.txt"). This works in both 
> >> 'system'
> >> and 'user' modes, is architecture-agnostic and introduces minimal noise on 
> >> the
> >> guest.
> >> 
> >> See first commit for a full description, use-cases and an example.
> >> 
> >> Signed-off-by: Lluís Vilanova <address@hidden>
> >> ---
> >> 
> >> Changes in v8
> >> =============
> >> 
> >> * Do not use 'seq' when there's no extra hypertrace arguments (BSD behaves
> >> differently for "seq 0").
> >> * Fix compilation for bsd-user.
> 
> > Hi Lluís,
> > Any changes regarding the fundamental approach since September 2016?
> 
> > Back then I had the following concerns about hypertrace for full-system
> > virtualization:
> 
> > Going to QEMU for every guest trace event has high overhead under
> > virtualization.  The alternative approach is recording separate traces
> > and merging them for analysis.  This is possible with trace-cmd [1] and
> > LTTng [2].
> 
> > Merging traces eliminates the performance bottleneck and does not
> > require new paravirt interfaces or guest tracing libraries.  I think it
> > it would be a distraction to support hypertrace for the virtualization
> > use case because it fundamentally has a high overhead.
> 
> > I see promise in using hypertrace for TCG because it is low-overhead
> > when running inside the QEMU process.  I'll review the patches again
> > with this in mind and not focus on virtualization.
> 
> > [1] https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg00887.html
> > [2] 
> > http://archive.eclipse.org/tracecompass/doc/stable/org.eclipse.tracecompass.doc.user/Virtual-Machine-Analysis.html
> >     and also generic trace synchronization
> >     
> > http://archive.eclipse.org/tracecompass/doc/stable/org.eclipse.tracecompass.doc.user/Trace-synchronization.html#Trace_synchronization
> 
> There's been no fundamental changes since then (just the few bits listed in 
> the
> v5-v8 changelog).
> 
> But I'm kind of split on this one.
> 
> If you want high-performance trace correlation, this will work much better for
> TCG than virtualization (where [1] will probably be more efficient).
> 
> If you want a hook to trigger other operations (like in the docs example), I
> think this is the right approach. In fact, my initial interest in hypertrace 
> was
> for instrumentation, so maybe this should be subsumed into the proposal of a
> stable instrumentation API.
> 
> What do you think?

That sounds good.

Stefan

signature.asc
Description: PGP signature