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]
Date:   Thu, 21 Sep 2017 22:08:13 -0300
From:   Marcelo Tosatti <mtosatti@...hat.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 2/3] KVM: x86: KVM_HC_RT_PRIO hypercall (host-side)

On Thu, Sep 21, 2017 at 03:49:33PM +0200, Paolo Bonzini wrote:
> On 21/09/2017 15:32, Konrad Rzeszutek Wilk wrote:
> > So the guest can change the scheduling decisions at the host level?
> > And the host HAS to follow it? There is no policy override for the
> > host to say - nah, not going to do it?

In that case the host should not even configure the guest with this
option (this is QEMU's 'enable-rt-fifo-hc' option).

> > Also wouldn't the guest want to always be at SCHED_FIFO? [I am thinking
> > of a guest admin who wants all the CPU resources he can get]

No. Because in the following code, executed by the housekeeping vCPU
running at constant SCHED_FIFO priority:

	1. Start disk I/O.
	2. busy spin

With the emulator thread sharing the same pCPU with the housekeeping
vCPU, the emulator thread (which runs at SCHED_NORMAL), will never
be scheduled in in place of the vcpu thread at SCHED_FIFO.

This causes a hang.

> Yeah, I do not understand why there should be a housekeeping VCPU that
> is running at SCHED_NORMAL.  If it hurts, don't do it...

Hope explanation above makes sense (in fact, it was you who pointed 
out SCHED_FIFO should not be constant on the housekeeping vCPU,
when sharing pCPU with emulator thread at SCHED_NORMAL).

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ