Re: [Qemu-devel] [RFC 22/48] cpu: hook plugin vcpu events

[Emilio G. Cota]

On Fri, Nov 23, 2018 at 17:10:53 +0000, Alex Bennée wrote:
> Emilio G. Cota <address@hidden> writes:
(snip)
> > @@ -1322,12 +1323,21 @@ static void qemu_tcg_rr_wait_io_event(CPUState *cpu)
> >
> >  static void qemu_wait_io_event(CPUState *cpu)
> >  {
> > +    bool asleep = false;
> > +
> 
> slept?

Changed to slept, thanks.

> >      g_assert(cpu_mutex_locked(cpu));
> >      g_assert(!qemu_mutex_iothread_locked());
> >
> >      while (cpu_thread_is_idle(cpu)) {
> > +        if (!asleep) {
> > +            asleep = true;
> > +            qemu_plugin_vcpu_idle_cb(cpu);
> > +        }
> >          qemu_cond_wait(&cpu->halt_cond, &cpu->lock);
> >      }
> > +    if (asleep) {
> > +        qemu_plugin_vcpu_resume_cb(cpu);
> > +    }
> 
> I wonder if having two hooks is too much? What might a plugin want to do
> before we go into idle sleep?
> 
> It feels like we are exposing too much of the guts of TCG to the plugin
> here as wait_io could be for any number of internal reasons other than
> the actual emulation blocking for IO through a WFI or something. If a
> plugin really wants to track such things shouldn't it be hooking to the
> guest sleep points?
> 
> If idle sleeps really are that important maybe we could just report our
> sleep time on resume - so a single hook but passing a bit more
> information?

I don't have all the use cases for this figured out. For now I'm using
this in plugins as a way to know when a vCPU is for sure idle, which
is used in memory reclamation schemes such as RCU.

What are the "guest sleep points" you mention? Are they target-agnostic?

Thanks,

                Emilio