[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v8 0/5] hypertrace: Lightweight guest-to-QEMU tr
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [PATCH v8 0/5] hypertrace: Lightweight guest-to-QEMU trace channel |
Date: |
Tue, 8 Aug 2017 13:25:15 +0100 |
User-agent: |
Mutt/1.8.3 (2017-05-23) |
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