[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <d80e440375896f75d45e227d40af60ca7ba24ceb.camel@redhat.com>
Date: Fri, 17 Dec 2021 12:51:57 +0100
From: Nicolas Saenz Julienne <nsaenzju@...hat.com>
To: Mark Rutland <mark.rutland@....com>, maz <maz@...nel.org>
Cc: Will Deacon <will@...nel.org>, paulmck <paulmck@...nel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
rcu <rcu@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>,
frederic <frederic@...nel.org>, kvmarm@...ts.cs.columbia.edu,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Possible nohz-full/RCU issue in arm64 KVM
Hi All,
arm64's guest entry code does the following:
int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
{
[...]
guest_enter_irqoff();
ret = kvm_call_hyp_ret(__kvm_vcpu_run, vcpu);
[...]
local_irq_enable();
/*
* We do local_irq_enable() before calling guest_exit() so
* that if a timer interrupt hits while running the guest we
* account that tick as being spent in the guest. We enable
* preemption after calling guest_exit() so that if we get
* preempted we make sure ticks after that is not counted as
* guest time.
*/
guest_exit();
[...]
}
On a nohz-full CPU, guest_{enter,exit}() delimit an RCU extended quiescent
state (EQS). Any interrupt happening between local_irq_enable() and
guest_exit() should disable that EQS. Now, AFAICT all el0 interrupt handlers do
the right thing if trggered in this context, but el1's won't. Is it possible to
hit an el1 handler (for example __el1_irq()) there?
Thanks,
--
Nicolás Sáenz
Powered by blists - more mailing lists