From: Fuad Tabba <fuad.tabba@linux.dev>
To: maz@kernel.org, oupton@kernel.org, kvmarm@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: catalin.marinas@arm.com, will@kernel.org, joey.gouly@arm.com,
seiden@linux.ibm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, vdonnefort@google.com, qperret@google.com,
tabba@google.com, mark.rutland@arm.com
Subject: [PATCH] KVM: arm64: Pend host SErrors for protected vCPUs through HCR_EL2.VSE
Date: Mon, 5 Oct 2026 06:03:52 +0100 [thread overview]
Message-ID: <20261005050352.836980-1-fuad.tabba@linux.dev> (raw)
kvm_inject_serror_esr() reads PSTATE.A and SCTLR2_EL1.NMEA to decide
whether to emulate the SError's exception entry or pend it through
HCR_EL2.VSE. For a protected vCPU, the host's copy of those is stale,
and when it reads as unmasked KVM emulates the entry on that copy. EL2
never delivers it as an SError: its entry handler turns the pending
exception into an external abort on the trapped access, and an MMIO
completion still pending trips WARN_ON(INCREMENT_PC).
Always pend through HCR_EL2.VSE for a protected vCPU. EL2 forwards it,
and the guest's own masking decides when the SError is taken.
Fixes: 872383bd12e11 ("KVM: arm64: Add per-EC entry/exit state marshalling for protected guests")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20261001142109.794CA1F000FF@smtp.kernel.org/
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
Applies on kvmarm/next. A follow-up to "KVM: arm64: Confine protected VM
vCPU state to EL2" [1], from Sashiko's review of its v4 patch 12.
[1] https://lore.kernel.org/all/20261001135711.1640520-1-fuad.tabba@linux.dev/
arch/arm64/kvm/inject_fault.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index d6c4fc16f8795..49a342b078365 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -378,8 +378,11 @@ int kvm_inject_serror_esr(struct kvm_vcpu *vcpu, u64 esr)
*
* As we're emulating the SError injection we need to explicitly populate
* ESR_ELx.EC because hardware will not do it on our behalf.
+ *
+ * A protected vCPU's PSTATE and SCTLR2_EL1 live at EL2, so pend through
+ * HCR_EL2.VSE and let the guest's own masking apply.
*/
- if (!serror_is_masked(vcpu)) {
+ if (!vcpu_is_protected(vcpu) && !serror_is_masked(vcpu)) {
pend_serror_exception(vcpu);
esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR) | ESR_ELx_IL;
vcpu_write_sys_reg(vcpu, esr, exception_esr_elx(vcpu));
base-commit: fa22cd9947fc245d71bc40482f7f78eb0d5a4af0
--
2.39.5
next reply other threads:[~2026-10-05 5:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 5:03 Fuad Tabba [this message]
2026-10-05 8:30 ` [PATCH] KVM: arm64: Pend host SErrors for protected vCPUs through HCR_EL2.VSE Marc Zyngier
2026-10-05 8:30 ` Oliver Upton
2026-10-05 10:34 ` Fuad Tabba
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=20261005050352.836980-1-fuad.tabba@linux.dev \
--to=fuad.tabba@linux.dev \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=qperret@google.com \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=vdonnefort@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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 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.