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, 31 Jul 2014 18:50:06 +0200
From:	Christoffer Dall <christoffer.dall@...aro.org>
To:	Peter Maydell <peter.maydell@...aro.org>
Cc:	Alex Bennée <alex.bennee@...aro.org>,
	kvm-devel <kvm@...r.kernel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	open list <linux-kernel@...r.kernel.org>,
	Gleb Natapov <gleb@...nel.org>,
	Paolo Bonzini <pbonzini@...hat.com>,
	"kvmarm@...ts.cs.columbia.edu" <kvmarm@...ts.cs.columbia.edu>,
	arm-mail-list <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] arm64: KVM: export current vcpu->pause state via pseudo
 regs

On Thu, Jul 31, 2014 at 05:45:28PM +0100, Peter Maydell wrote:
> On 31 July 2014 17:38, Christoffer Dall <christoffer.dall@...aro.org> wrote:
> >> > If we are not complaining when setting the pause value to false if it
> >> > was true before, then we probably also need to wake up the thread in
> >> > case this is called from another thread, right?
> >> >
> >> > or perhaps we should just return an error if you're trying to un-pause a
> >> > CPU through this interface, hmmmm.
> >>
> >> Wouldn't it be an error to mess with any register when the system is not
> >> in a quiescent state? I was assuming that the wake state is dealt with
> >> when the run loop finally restarts.
> >>
> >
> > The ABI doesn't really define it as an error (the ABI doesn't enforce
> > anything right now) so the question is, does it ever make sense to clear
> > the pause flag through this ioctl?  If not, I think we should just err
> > on the side of caution and specify in the docs that this is not
> > supported and return an error.
> 
> Consider the case where the reset state of the system is
> "CPU 0 running, CPUs 1..N stopped", and we're doing an
> incoming migration to a state where all CPUs are running.
> In that case we'll be using this ioctl to clear the pause flag,
> right? (We'll also obviously need to set the PC and other
> register state correctly before resuming the guest.)
> 
Doh, you're right, I somehow had it in my mind that when you send the
thread a signal, the pause flag would be cleared, but that goes against
the whole idea of a CPU being turned off for KVM.

But wouldn't we then have to also wake up the thread when clearing the
pause flag?  It feels strange that the ioctl can clear the pause flag,
but keep the thread on a wake-queue, and then userspace has to send the
thread a signal of some sort to wake it up?

-Christoffer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ