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 <vilan...@ac.upc.edu> > >> --- > >> > >> 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  and > > LTTng . > > > 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. > > >  https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg00887.html > >  > > 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  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
Description: PGP signature