From: pbonzini@redhat.com (Paolo Bonzini)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: KVM: export current vcpu->pause state via pseudo regs
Date: Thu, 31 Jul 2014 19:21:44 +0200 [thread overview]
Message-ID: <53DA7B28.701@redhat.com> (raw)
In-Reply-To: <CAFEAcA9cT617t8JqOXtuO-wQ5xg5T3Sw_DUHB1fpPD6g3SSNaQ@mail.gmail.com>
Il 31/07/2014 19:04, Peter Maydell ha scritto:
> On 31 July 2014 17:57, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 09/07/2014 15:55, Alex Benn?e ha scritto:
>>> To cleanly restore an SMP VM we need to ensure that the current pause
>>> state of each vcpu is correctly recorded. Things could get confused 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 VM
>>> controller (e.g. QEMU).
>>>
>>> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>>> ---
>>> 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 the
>> existing KVM_GET/SET_MP_STATE ioctl interface?
>
> That appears to be an x86-specific thing relating to
> IRQ chips.
No, it's not. It's just the state of the CPU, s390 will be using it too.
On x86 the states are uninitialized (UNINITIALIZED), stopped
(INIT_RECEIVED), running (RUNNABLE), halted (HALTED). CPU 0 starts in
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.
>> Also, how is KVM/ARM
>> representing (and passing to QEMU) the halted state of the
>> VCPU?
>
> We don't. In ARM the equivalent of x86 HLT (which is
> WFI, wait-for-interrupt) is allowed to resume at any time.
> So we don't need to care about saving and restoring
> whether we were sat in a WFI at point of migration.
What does ARM do if you have a WFI while interrupts are disabled? On
x86 after "cli;hlt" only an NMI will wake you up. With spurious
wakeups, it's pretty much guaranteed that you will break such "cli;hlt"
sequences.
Paolo
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
arm-mail-list <linux-arm-kernel@lists.infradead.org>,
kvm-devel <kvm@vger.kernel.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will.deacon@arm.com>,
"open list" <linux-kernel@vger.kernel.org>,
"Gleb Natapov" <gleb@kernel.org>
Subject: Re: [PATCH] arm64: KVM: export current vcpu->pause state via pseudo regs
Date: Thu, 31 Jul 2014 19:21:44 +0200 [thread overview]
Message-ID: <53DA7B28.701@redhat.com> (raw)
In-Reply-To: <CAFEAcA9cT617t8JqOXtuO-wQ5xg5T3Sw_DUHB1fpPD6g3SSNaQ@mail.gmail.com>
Il 31/07/2014 19:04, Peter Maydell ha scritto:
> On 31 July 2014 17:57, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 09/07/2014 15:55, Alex Bennée ha scritto:
>>> To cleanly restore an SMP VM we need to ensure that the current pause
>>> state of each vcpu is correctly recorded. Things could get confused 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 VM
>>> controller (e.g. QEMU).
>>>
>>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>>> ---
>>> 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 the
>> existing KVM_GET/SET_MP_STATE ioctl interface?
>
> That appears to be an x86-specific thing relating to
> IRQ chips.
No, it's not. It's just the state of the CPU, s390 will be using it too.
On x86 the states are uninitialized (UNINITIALIZED), stopped
(INIT_RECEIVED), running (RUNNABLE), halted (HALTED). CPU 0 starts in
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.
>> Also, how is KVM/ARM
>> representing (and passing to QEMU) the halted state of the
>> VCPU?
>
> We don't. In ARM the equivalent of x86 HLT (which is
> WFI, wait-for-interrupt) is allowed to resume at any time.
> So we don't need to care about saving and restoring
> whether we were sat in a WFI at point of migration.
What does ARM do if you have a WFI while interrupts are disabled? On
x86 after "cli;hlt" only an NMI will wake you up. With spurious
wakeups, it's pretty much guaranteed that you will break such "cli;hlt"
sequences.
Paolo
next prev parent reply other threads:[~2014-07-31 17:21 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-09 13:55 [PATCH] arm64: KVM: export current vcpu->pause state via pseudo regs Alex Bennée
2014-07-09 13:55 ` Alex Bennée
2014-07-31 14:35 ` Christoffer Dall
2014-07-31 14:35 ` Christoffer Dall
2014-07-31 15:14 ` Alex Bennée
2014-07-31 15:14 ` Alex Bennée
2014-07-31 16:38 ` Christoffer Dall
2014-07-31 16:38 ` Christoffer Dall
2014-07-31 16:45 ` Peter Maydell
2014-07-31 16:45 ` Peter Maydell
2014-07-31 16:50 ` Christoffer Dall
2014-07-31 16:50 ` Christoffer Dall
2014-07-31 16:53 ` Peter Maydell
2014-07-31 16:53 ` Peter Maydell
2014-08-01 9:48 ` Alex Bennée
2014-08-01 9:48 ` Alex Bennée
2014-08-04 12:11 ` Christoffer Dall
2014-08-04 12:11 ` Christoffer Dall
2014-08-01 9:11 ` Alex Bennée
2014-08-01 9:11 ` Alex Bennée
2014-08-04 12:13 ` Christoffer Dall
2014-08-04 12:13 ` Christoffer Dall
2014-07-31 16:57 ` Paolo Bonzini
2014-07-31 16:57 ` Paolo Bonzini
2014-07-31 17:04 ` Peter Maydell
2014-07-31 17:04 ` Peter Maydell
2014-07-31 17:21 ` Paolo Bonzini [this message]
2014-07-31 17:21 ` Paolo Bonzini
2014-07-31 17:36 ` Peter Maydell
2014-07-31 17:36 ` Peter Maydell
2014-07-31 17:44 ` Will Deacon
2014-07-31 17:44 ` Will Deacon
2014-08-04 12:16 ` Christoffer Dall
2014-08-04 12:16 ` Christoffer Dall
2014-08-04 12:35 ` Alex Bennée
2014-08-04 12:35 ` Alex Bennée
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53DA7B28.701@redhat.com \
--to=pbonzini@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.