From: Andrew Jones <drjones@redhat.com>
To: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Cc: marc.zyngier@arm.com, cdall@linaro.org, pbonzini@redhat.com
Subject: [PATCH v3 04/10] KVM: arm/arm64: use vcpu request in kvm_arm_halt_vcpu
Date: Wed, 3 May 2017 18:06:29 +0200 [thread overview]
Message-ID: <20170503160635.21669-5-drjones@redhat.com> (raw)
In-Reply-To: <20170503160635.21669-1-drjones@redhat.com>
VCPU halting/resuming is partially implemented with VCPU requests.
When kvm_arm_halt_guest() is called all VCPUs get the EXIT request,
telling them to exit guest mode and look at the state of 'pause',
which will be true, telling them to sleep. As ARM's VCPU RUN
implements the memory barrier pattern described in "Ensuring Requests
Are Seen" of Documentation/virtual/kvm/vcpu-requests.rst, there's
no way for a VCPU halted by kvm_arm_halt_guest() to miss the pause
state change. However, before this patch, a single VCPU halted with
kvm_arm_halt_vcpu() did not get a request, opening a tiny race window.
This patch adds the request, closing the race window and also allowing
us to remove the final check of pause in VCPU RUN, as the final check
for requests is sufficient.
Signed-off-by: Andrew Jones <drjones@redhat.com>
---
I have two questions about the halting/resuming.
Question 1:
Do we even need kvm_arm_halt_vcpu()/kvm_arm_resume_vcpu()? It should
only be necessary if one VCPU can activate or inactivate the private
IRQs of another VCPU, right? That doesn't seem like something that
should be possible, but I'm GIC-illiterate...
Question 2:
It's not clear to me if we have another problem with halting/resuming
or not. If it's possible for VCPU1 and VCPU2 to race in
vgic_mmio_write_s/cactive(), then the following scenario could occur,
leading to VCPU3 being in guest mode when it should not be. Does the
hardware prohibit more than one VCPU entering trap handlers that lead
to these functions at the same time? If not, then I guess pause needs
to be a counter instead of a boolean.
VCPU1 VCPU2 VCPU3
----- ----- -----
VCPU3->pause = true;
halt(VCPU3);
if (pause)
sleep();
VCPU3->pause = true;
halt(VCPU3);
VCPU3->pause = false;
resume(VCPU3);
...wake up...
if (!pause)
Enter guest mode. Bad!
VCPU3->pause = false;
resume(VCPU3);
(Yes, the "Bad!" is there to both identify something we don't want
occurring and to make fun of Trump's tweeting style.)
---
arch/arm/kvm/arm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 47f6c7fdca96..9174ed13135a 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -545,6 +545,7 @@ void kvm_arm_halt_guest(struct kvm *kvm)
void kvm_arm_halt_vcpu(struct kvm_vcpu *vcpu)
{
vcpu->arch.pause = true;
+ kvm_make_request(KVM_REQ_VCPU_EXIT, vcpu);
kvm_vcpu_kick(vcpu);
}
@@ -664,7 +665,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
if (ret <= 0 || need_new_vmid_gen(vcpu->kvm) ||
kvm_request_pending(vcpu) ||
- vcpu->arch.power_off || vcpu->arch.pause) {
+ vcpu->arch.power_off) {
vcpu->mode = OUTSIDE_GUEST_MODE;
local_irq_enable();
kvm_pmu_sync_hwstate(vcpu);
--
2.9.3
next prev parent reply other threads:[~2017-05-03 16:06 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-03 16:06 [PATCH v3 00/10] KVM: arm/arm64: race fixes and vcpu requests Andrew Jones
2017-05-03 16:06 ` [PATCH v3 01/10] KVM: add kvm_request_pending Andrew Jones
2017-05-03 16:06 ` [PATCH v3 02/10] KVM: Add documentation for VCPU requests Andrew Jones
2017-05-04 11:27 ` Paolo Bonzini
2017-05-04 12:06 ` Andrew Jones
2017-05-04 12:51 ` Paolo Bonzini
2017-05-04 13:31 ` Andrew Jones
2017-05-03 16:06 ` [PATCH v3 03/10] KVM: arm/arm64: prepare to use vcpu requests Andrew Jones
2017-05-03 16:06 ` Andrew Jones [this message]
2017-05-06 18:08 ` [PATCH v3 04/10] KVM: arm/arm64: use vcpu request in kvm_arm_halt_vcpu Christoffer Dall
2017-05-09 17:02 ` Andrew Jones
2017-05-10 9:59 ` Christoffer Dall
2017-05-15 11:14 ` Christoffer Dall
2017-05-16 2:17 ` Andrew Jones
2017-05-16 10:06 ` Christoffer Dall
2017-05-03 16:06 ` [PATCH v3 05/10] KVM: arm/arm64: don't clear exit request from caller Andrew Jones
2017-05-06 18:12 ` Christoffer Dall
2017-05-09 17:17 ` Andrew Jones
2017-05-10 9:55 ` Christoffer Dall
2017-05-10 10:07 ` Andrew Jones
2017-05-10 12:19 ` Christoffer Dall
2017-05-03 16:06 ` [PATCH v3 06/10] KVM: arm/arm64: use vcpu requests for power_off Andrew Jones
2017-05-06 18:17 ` Christoffer Dall
2017-05-03 16:06 ` [PATCH v3 07/10] KVM: arm/arm64: optimize VCPU RUN Andrew Jones
2017-05-06 18:27 ` Christoffer Dall
2017-05-09 17:40 ` Andrew Jones
2017-05-09 20:13 ` Christoffer Dall
2017-05-10 6:58 ` Andrew Jones
2017-05-10 8:07 ` Christoffer Dall
2017-05-10 8:20 ` Andrew Jones
2017-05-10 9:06 ` Christoffer Dall
2017-05-03 16:06 ` [PATCH v3 08/10] KVM: arm/arm64: change exit request to sleep request Andrew Jones
2017-05-04 11:38 ` Paolo Bonzini
2017-05-04 12:07 ` Andrew Jones
2017-05-03 16:06 ` [PATCH v3 09/10] KVM: arm/arm64: use vcpu requests for irq injection Andrew Jones
2017-05-04 11:47 ` Paolo Bonzini
2017-05-06 18:49 ` Christoffer Dall
2017-05-08 8:48 ` Paolo Bonzini
2017-05-08 8:56 ` Christoffer Dall
2017-05-06 18:51 ` Christoffer Dall
2017-05-09 17:53 ` Andrew Jones
2017-05-03 16:06 ` [PATCH v3 10/10] KVM: arm/arm64: PMU: remove request-less vcpu kick Andrew Jones
2017-05-06 18:55 ` Christoffer Dall
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=20170503160635.21669-5-drjones@redhat.com \
--to=drjones@redhat.com \
--cc=cdall@linaro.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=marc.zyngier@arm.com \
--cc=pbonzini@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox