Re: [PATCH v2] kvm: Replace vcpu->swait with rcuwait

[Davidlohr Bueso]

On Tue, 21 Apr 2020, Paolo Bonzini wrote:

> On 20/04/20 23:50, Davidlohr Bueso wrote:
> > On Mon, 20 Apr 2020, Paolo Bonzini wrote:
> >
> > > On 20/04/20 22:56, Davidlohr Bueso wrote:
> > > > On Mon, 20 Apr 2020, Marc Zyngier wrote:
> > > >
> > > > > This looks like a change in the semantics of the tracepoint. Before
> > > > > this
> > > > > change, 'waited' would have been true if the vcpu waited at all. Here,
> > > > > you'd
> > > > > have false if it has been interrupted by a signal, even if the vcpu
> > > > > has waited
> > > > > for a period of time.
> > > >
> > > > Hmm but sleeps are now uninterruptible as we're using TASK_IDLE.
> > >
> > > Hold on, does that mean that you can't anymore send a signal in order to
> > > kick a thread out of KVM_RUN?  Or am I just misunderstanding?
> >
> > Considering that the return value of the interruptible wait is not
> > checked, I would not think this breaks KVM_RUN.
>
> What return value?  kvm_vcpu_check_block checks signal_pending, so you
> could have a case where the signal is injected but you're not woken up.
>
> Admittedly I am not familiar with how TASK_* work under the hood, but it
> does seem to be like that.

I should have looked closer here - I was thinking about the return value
of rcuwait_wait_event. Yes, that signal_pending check you mention makes
the sleep semantics change bogus as interruptible is no longer just to
avoid contributing to the load balance.

And yes, unfortunately adding prepare_to and finish_rcuwait() looks like the
most reasonable approach to keeping the tracepoint semantics. I also considered
extending rcuwait_wait_event() by another parameter to pass back to the caller
if there was any wait at all, but that enlarges the call and is probably less
generic.

I'll send another version keeping the current sleep and tracepoint semantics.

Thanks,
Davidlohr