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

[Marcelo Tosatti <mtosatti@redhat.com>]

On Mon, Sep 25, 2017 at 11:13:16AM +0200, 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."
> > 
> > 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.
> > 
> > (*)
> > 
> > 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).

True. Could add the "i am in a critical section" notifier to those
constructs as well, which would call the hypercall.

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

It is needed only when not in a critical section.
And when in a critical section, the vcpu should not get interrupted.

But the solution to reserve one pCPU per socket, to run all emulator
threads, achieves reasonable packing numbers without the downsides
of the hypercall.