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

[Alex Bennée]

Emilio G. Cota <address@hidden> writes:

> 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.

Couldn't we achieve the same by scheduling async or safe async work on
the vCPU? Maybe we would expose this to the plugin as a "run callback
when idle" function.

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

I mean we can arrive here for a variety of reasons - not all of which
are triggered by the guest going to sleep. But that isn't your current
use case.

They aren't target agnostic as not all guests try to fully model their
"sleeping" instructions. Some just end up busy spinning until the event
they should have been sleeping until happens.

>
> Thanks,
>
>               Emilio


--
Alex Bennée