qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] trace: Add "cpu_init" event


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH 1/2] trace: Add "cpu_init" event
Date: Thu, 15 Sep 2016 13:10:31 +0100
User-agent: Mutt/1.7.0 (2016-08-17)

On Wed, Sep 14, 2016 at 06:01:17PM +0200, Lluís Vilanova wrote:
> Stefan Hajnoczi writes:
> 
> > On Tue, Sep 06, 2016 at 04:25:53PM +0200, Lluís Vilanova wrote:
> >> +## vCPU
> >> +
> >> +# Create a new virtual (guest) CPU
> >> +#
> >> +# Targets: all
> >> +guest_cpu_init(void *cpu) "cpu=%p"
> 
> > This isn't a vcpu trace event.  Please add keep it with the other
> > non-vcpu trace events:
> 
> > # cpus.c
> > guest_cpu_init(void *cpu) "cpu=%p"
> 
> It actually is, but as the commit message says, declaring it as such prevents
> the event to be emitted.

If it cannot be toggled on a per-vcpu basis then claiming it's a vcpu
event doesn't make sense.

> The culprit of this problem is that new vCPUs start with an empty per-vCPU 
> trace
> event set. Should we make vCPUs "inherit" the state from the global state?
> (i.e., if any vcpu event is set on any vCPU, set it on the new one). The next
> question would then be, should this inheritance only apply until tracing is
> fully initialized of for the whole duration of QEMU?

I think the underlying issue is that trace_init_vcpu_events() assumes
there is a single instant where vcpus all exist and need to be
initialized.

A model that supports vcpu hotplug is really needed.  In that model the
global dstate should be the "global" state that determines whether vcpus
are initialized with the event enabled or disabled.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]