mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: linux-kernel@vger.kernel.org
Cc: aleksandar.qemu.devel@gmail.com, alexandru.elisei@arm.com,
	anup.patel@wdc.com, aou@eecs.berkeley.edu, atish.patra@wdc.com,
	borntraeger@linux.ibm.com, bp@alien8.de, catalin.marinas@arm.com,
	chenhuacai@kernel.org, dave.hansen@linux.intel.com,
	frankja@linux.ibm.com, frederic@kernel.org, gor@linux.ibm.com,
	hca@linux.ibm.com, james.morse@arm.com, jmattson@google.com,
	joro@8bytes.org, luto@kernel.org, mark.rutland@arm.com,
	maz@kernel.org, mingo@redhat.com, mpe@ellerman.id.au,
	nsaenzju@redhat.com, palmer@dabbelt.com, paulmck@kernel.org,
	paul.walmsley@sifive.com, pbonzini@redhat.com,
	peterz@infradead.org, seanjc@google.com, suzuki.poulose@arm.com,
	svens@linux.ibm.com, tglx@linutronix.de,
	tsbogend@alpha.franken.de, vkuznets@redhat.com,
	wanpengli@tencent.com, will@kernel.org
Subject: [PATCH v2 4/7] kvm/mips: rework guest entry logic
Date: Wed, 19 Jan 2022 10:58:51 +0000	[thread overview]
Message-ID: <20220119105854.3160683-5-mark.rutland@arm.com> (raw)
In-Reply-To: <20220119105854.3160683-1-mark.rutland@arm.com>

In kvm_arch_vcpu_ioctl_run() we use guest_enter_irqoff() and
guest_exit_irqoff() directly, with interrupts masked between these. As
we don't handle any timer ticks during this window, we will not account
time spent within the guest as guest time, which is unfortunate.

Additionally, we do not inform lockdep or tracing that interrupts will
be enabled during guest execution, which caan lead to misleading traces
and warnings that interrupts have been enabled for overly-long periods.

This patch fixes these issues by using the new timing and context
entry/exit helpers to ensure that interrupts are handled during guest
vtime but with RCU watching, with a sequence:

	guest_timing_enter_irqoff();

	guest_state_enter_irqoff();
	< run the vcpu >
	guest_state_exit_irqoff();

	< take any pending IRQs >

	guest_timing_exit_irqoff();

Since instrumentation may make use of RCU, we must also ensure that no
instrumented code is run during the EQS. I've split out the critical
section into a new kvm_mips_enter_exit_vcpu() helper which is marked
noinstr.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Paul E. McKenney <paulmck@kernel.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
 arch/mips/kvm/mips.c | 37 ++++++++++++++++++++++++++++++++++---
 1 file changed, 34 insertions(+), 3 deletions(-)

diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
index aa20d074d3883..1a961c2434fee 100644
--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -438,6 +438,24 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
 	return -ENOIOCTLCMD;
 }
 
+/*
+ * Actually run the vCPU, entering an RCU extended quiescent state (EQS) while
+ * the vCPU is running.
+ *
+ * This must be noinstr as instrumentation may make use of RCU, and this is not
+ * safe during the EQS.
+ */
+static int noinstr kvm_mips_vcpu_enter_exit(struct kvm_vcpu *vcpu)
+{
+	int ret;
+
+	guest_state_enter_irqoff();
+	ret = kvm_mips_callbacks->vcpu_run(vcpu);
+	guest_state_exit_irqoff();
+
+	return ret;
+}
+
 int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
 {
 	int r = -EINTR;
@@ -458,7 +476,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
 	lose_fpu(1);
 
 	local_irq_disable();
-	guest_enter_irqoff();
+	guest_timing_enter_irqoff();
 	trace_kvm_enter(vcpu);
 
 	/*
@@ -469,10 +487,23 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
 	 */
 	smp_store_mb(vcpu->mode, IN_GUEST_MODE);
 
-	r = kvm_mips_callbacks->vcpu_run(vcpu);
+	r = kvm_mips_vcpu_enter_exit(vcpu);
+
+	/*
+	 * We must ensure that any pending interrupts are taken before
+	 * we exit guest timing so that timer ticks are accounted as
+	 * guest time. Transiently unmask interrupts so that any
+	 * pending interrupts are taken.
+	 *
+	 * TODO: is there a barrier which ensures that pending interrupts are
+	 * recognised? Currently this just hopes that the CPU takes any pending
+	 * interrupts between the enable and disable.
+	 */
+	local_irq_enable();
+	local_irq_disable();
 
 	trace_kvm_out(vcpu);
-	guest_exit_irqoff();
+	guest_timing_exit_irqoff();
 	local_irq_enable();
 
 out:
-- 
2.30.2


  parent reply	other threads:[~2022-01-19 10:59 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-19 10:58 [PATCH v2 0/7] kvm: fix latent guest entry/exit bugs Mark Rutland
2022-01-19 10:58 ` [PATCH v2 1/7] entry: add arch_in_rcu_eqs() Mark Rutland
2022-01-19 17:35   ` Christian Borntraeger
2022-01-21 17:34   ` Nicolas Saenz Julienne
2022-01-19 10:58 ` [PATCH v2 2/7] kvm: add guest_state_{enter,exit}_irqoff() Mark Rutland
2022-01-20 11:00   ` Paolo Bonzini
2022-01-21 17:35   ` Nicolas Saenz Julienne
2022-01-19 10:58 ` [PATCH v2 3/7] kvm/arm64: rework guest entry logic Mark Rutland
2022-01-21 17:37   ` Nicolas Saenz Julienne
2022-01-19 10:58 ` Mark Rutland [this message]
2022-01-20 11:10   ` [PATCH v2 4/7] kvm/mips: " Paolo Bonzini
2022-01-20 13:33     ` Mark Rutland
2022-01-20 16:44   ` Mark Rutland
2022-01-20 16:57     ` Paolo Bonzini
2022-01-20 17:15       ` Mark Rutland
2022-01-20 17:17         ` Sean Christopherson
2022-01-20 17:29         ` Paolo Bonzini
2022-01-21 12:44           ` Mark Rutland
2022-01-19 10:58 ` [PATCH v2 5/7] kvm/riscv: " Mark Rutland
2022-01-20 11:18   ` Paolo Bonzini
2022-01-20 12:56     ` Mark Rutland
2022-01-20 13:13       ` Paolo Bonzini
2022-01-19 10:58 ` [PATCH v2 6/7] kvm/s390: " Mark Rutland
2022-01-19 10:58 ` [PATCH v2 7/7] kvm/x86: " Mark Rutland
2022-01-20 11:20   ` Paolo Bonzini
2022-01-21 17:40   ` Nicolas Saenz Julienne
2022-01-19 18:25 ` [PATCH v2 0/7] kvm: fix latent guest entry/exit bugs Christian Borntraeger
2022-01-19 18:28   ` Christian Borntraeger
2022-01-19 19:22   ` Mark Rutland
2022-01-19 19:30     ` Christian Borntraeger
2022-01-20 11:57       ` Mark Rutland
2022-01-20 12:02         ` Christian Borntraeger
2022-01-20 11:28     ` Paolo Bonzini
2022-01-20 12:03       ` Mark Rutland
2022-01-20 15:14         ` Christian Borntraeger
2022-01-21  9:53           ` Christian Borntraeger
2022-01-21 14:17             ` Christian Borntraeger
2022-01-21 14:30               ` Mark Rutland
2022-01-21 14:42                 ` Christian Borntraeger
2022-01-21 15:29                   ` Mark Rutland
2022-01-21 15:40                     ` Christian Borntraeger

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=20220119105854.3160683-5-mark.rutland@arm.com \
    --to=mark.rutland@arm.com \
    --cc=aleksandar.qemu.devel@gmail.com \
    --cc=alexandru.elisei@arm.com \
    --cc=anup.patel@wdc.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=atish.patra@wdc.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=frankja@linux.ibm.com \
    --cc=frederic@kernel.org \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=james.morse@arm.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=maz@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=nsaenzju@redhat.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=paulmck@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=seanjc@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=svens@linux.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=tsbogend@alpha.franken.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®