From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [PATCH] arm64: KVM: export current vcpu->pause state via pseudo regs Date: Mon, 4 Aug 2014 14:16:55 +0200 Message-ID: <20140804121655.GE524@cbox> References: <1404914112-7298-1-git-send-email-alex.bennee@linaro.org> <53DA7583.2030504@redhat.com> <53DA7B28.701@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Peter Maydell , kvm-devel , Gleb Natapov , Catalin Marinas , Will Deacon , open list , "kvmarm@lists.cs.columbia.edu" , arm-mail-list , Paolo Bonzini To: Alex Bennee Return-path: Content-Disposition: inline In-Reply-To: <53DA7B28.701@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Thu, Jul 31, 2014 at 07:21:44PM +0200, Paolo Bonzini wrote: > Il 31/07/2014 19:04, Peter Maydell ha scritto: > > On 31 July 2014 17:57, Paolo Bonzini wrote: > >> Il 09/07/2014 15:55, Alex Benn=E9e ha scritto: > >>> To cleanly restore an SMP VM we need to ensure that the current p= ause > >>> state of each vcpu is correctly recorded. Things could get confus= ed if > >>> the CPU starts running after migration restore completes when it = was > >>> paused before it state was captured. > >>> > >>> I've done this by exposing a register (currently only 1 bit used)= via > >>> the GET/SET_ONE_REG logic to pass the state between KVM and the V= M > >>> controller (e.g. QEMU). > >>> > >>> Signed-off-by: Alex Benn=E9e > >>> --- > >>> arch/arm64/include/uapi/asm/kvm.h | 8 +++++ > >>> arch/arm64/kvm/guest.c | 61 +++++++++++++++++++++++++= +++++++++++++- > >>> 2 files changed, 68 insertions(+), 1 deletion(-) > >> > >> Since it's a pseudo register anyway, would it make sense to use th= e > >> existing KVM_GET/SET_MP_STATE ioctl interface? > >=20 > > That appears to be an x86-specific thing relating to > > IRQ chips. >=20 > No, it's not. It's just the state of the CPU, s390 will be using it = too. >=20 > On x86 the states are uninitialized (UNINITIALIZED), stopped > (INIT_RECEIVED), running (RUNNABLE), halted (HALTED). CPU 0 starts i= n > RUNNABLE state, other CPUs start in UNINITIALIZED state. There are > x86-specific cases (uninitialized) and x86-isms (the INIT_RECEIVED > name), but the idea is widely applicable. >=20 Alex, I think it makes perfect sense to use GET/SET_MP_STATE, will you revise the patch? (Don't forget to update the documentation to reflect it is now supporte= d on ARM, and which states are used to represent what there.) Thanks, -Christoffer