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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 22 Sep 2017 14:55:56 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Marcelo Tosatti <mtosatti@...hat.com>
Cc:     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 Fri, Sep 22, 2017 at 09:33:05AM -0300, Marcelo Tosatti wrote:
> > That is, running a RT guest and not having _all_ VCPUs being RT tasks on
> > the host is absolutely and completely insane and broken.
> 
> Can you explain why, please?

You just explained it yourself. If the thread that needs to complete
what you're waiting on has lower priority, it will _never_ get to run if
you're busy waiting on it.

This is _trivial_.

And even for !RT it can be quite costly, because you can end up having
to burn your entire slot of CPU time before you run the other task.

Userspace spinning is _bad_, do not do this.

(the one exception where it works is where you have a single thread per
cpu, because then there's effectively no scheduling).

> > Fix whatever needs fixing to allow your VCPU0 to be RT, don't do insane
> > things like this.
> 
> VCPU0 can be RT, but you'll get the following hang, if the emulator
> thread is sharing a pCPU with VCPU0:
> 
> 	1. submit IO.
> 	2. busy spin.
> 
> As executed by the guest vcpu (its a natural problem).
> 
> Do you have a better suggestion as how to fix the problem?

Yes, not busy wait. Go to sleep and make sure you're woken up once the
IO completes.

> We can fix the BIOS, but userspace will still be allowed to
> generate the code pattern above.

What does the BIOS have to do with anything?

> And increasing the priority of the emulator thread, at random times 
> (so it can inject interrupts to vcpu-0), can cause it to interrupt 
> vcpu-0 in a spinlock protected section.

You can equally boost the emulator thread while you're spin-waiting, but
that's ugly as heck too.

The normal, sane solution is to not spin-wait but block.