Re: [patch 3/3] x86: kvm guest side support for KVM_HC_RT_PRIO hypercall

[Paolo Bonzini <pbonzini@redhat.com>]

On 25/09/2017 11:13, Peter Zijlstra wrote:
> On Sun, Sep 24, 2017 at 11:57:53PM -0300, Marcelo Tosatti wrote:
>> I think you are missing the following point:
>>
>> "vcpu0 can be interrupted when its not in a spinlock protected section, 
>> otherwise it can't."

Who says that?  Certainly a driver can dedicate a single VCPU to
periodic polling of the device, in such a way that the polling does not
require a spinlock.

>> So you _have_ to communicate to the host when the guest enters/leaves a
>> critical section.
>>
>> So this point of "everything needs to be RT and the priorities must be
>> designed carefully", is this: 
>>
>> 	WHEN in spinlock protected section (more specifically, when 
>> 	spinlock protected section _shared with realtime vcpus_),
>>
>> 	priority of vcpu0 > priority of emulator thread
>>
>> 	OTHERWISE
>>
>> 	priority of vcpu0 < priority of emulator thread.

This is _not_ designed carefully, this is messy.

The emulator thread can interrupt the VCPU thread, so it has to be at
higher RT priority (+ priority inheritance of mutexes).  Once you have
done that we can decide on other approaches that e.g. let you get more
sharing by placing housekeeping VCPUs at SCHED_NORMAL or SCHED_RR.

>> So emulator thread can interrupt and inject interrupts to vcpu0.
> 
> spinlock protected regions are not everything. What about lock-free
> constructs where CPU's spin-wait on one another (there's plenty).
> 
> And I'm clearly ignorant of how this emulation thread works, but why
> would it run for a long time? Either it is needed for forward progress
> of the VCPU or its not. If its not, it shouldn't run.

The emulator thread 1) should not run for long period of times indeed,
and 2) it is needed for forward progress of the VCPU.  So it has to be
at higher RT priority.  I agree with Peter, sorry.  Spinlocks are a red
herring here.

Paolo