linux-kernel - Re: [patch 3/3] x86: kvm guest side support for KVM_HC_RT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170926232230.GA8962@amt.cnet>
Date:   Tue, 26 Sep 2017 20:22:30 -0300
From:   Marcelo Tosatti <mtosatti@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        mingo@...hat.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch 3/3] x86: kvm guest side support for KVM_HC_RT_PRIO
 hypercall

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.