From: Marc Zyngier <maz@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev,
"Oliver\ Upton" <oupton@kernel.org>
Subject: Re: [PATCH v4 03/29] KVM: arm64: Merge guest's HCRX_EL2 using NV_HCRX_GUEST_EXCLUDE
Date: Thu, 30 Jul 2026 09:01:33 +0100 [thread overview]
Message-ID: <86o6fodhya.wl-maz@kernel.org> (raw)
In-Reply-To: <20260730072930.85DB21F000E9@smtp.kernel.org>
On Thu, 30 Jul 2026 08:29:29 +0100,
sashiko-bot@kernel.org wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] The NV_HCRX_GUEST_EXCLUDE macro fails to exclude HCRX_EL2_MCE2, allowing a nested hypervisor to break KVM's transparent MOPS migration handling.
> --
>
> --- Patch [3]: [PATCH v4 03/29] KVM: arm64: Merge guest's HCRX_EL2 using NV_HCRX_GUEST_EXCLUDE ---
> commit 32a9437b5c31bcb57be7ba071a094800d7980587
> Author: Marc Zyngier <maz@kernel.org>
>
> KVM: arm64: Merge guest's HCRX_EL2 using NV_HCRX_GUEST_EXCLUDE
>
> This commit refactors HCRX_EL2 handling by introducing a macro that
> explicitly lists the bits excluded from the merge, preventing the nested
> guest from overriding them.
>
> > diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> > index 18131e395e24c..0903e08f4b6a0 100644
> > --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> > +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
>
> [ ... ]
>
> > @@ -325,6 +325,24 @@ static inline void __deactivate_traps_mpam(void)
> > write_sysreg_s(MPAMHCR_HOST_FLAGS, SYS_MPAMHCR_EL2);
> > }
> >
> > +/*
> > + * Just like for HCR_EL2, we can't let the guest mess with some of the
> > + * basics we rely on in HCRX_EL2. However, the major difference is that
> > + * HCRX_EL2 only affects EL1, and never EL2 (sudden outburst of sanity, I
> > + * guess). So it is always the guest inflicting it on its own guestx.
> > + *
> > + * Things we don't want to let the guest control are:
> > + *
> > + * - TMEA: That's for us to decide how an SEA is routed, not the guest.
> > + *
> > + * - PTTWI: Similarly, it is for us to decide whether Reduced Coherency for
> > + * the PTW is a thing. It really isn't.
> > + *
> > + * - EnIDCP128: We don't allow IMPDEF sysregs -- full stop.
> > + */
> > +#define NV_HCRX_GUEST_EXCLUDE (HCRX_EL2_TMEA | HCRX_EL2_PTTWI | \
> > + HCRX_EL2_EnIDCP128)
>
> [Severity: High]
> This isn't a bug introduced by this patch, but since NV_HCRX_GUEST_EXCLUDE
> enumerates the bits the nested guest is not allowed to override, should
> HCRX_EL2_MCE2 be excluded here as well?
>
> KVM (L0) relies on intercepting MOPS exceptions (via HCRX_EL2.MCE2=1) to
> handle vCPU physical migrations transparently. If L0 merges a value from the
> L1 hypervisor that sets MCE2 to 0 (which happens naturally if L1 does not
> support MOPS),
If L1 doesn't support MOPS, then HCRX_EL2.MCEn==0, and the
instructions UNDEF.
> and L0 then migrates the physical CPU while L2 is executing a
> MOPS instruction, the MOPS exception could trap to EL1 (L2) instead of
> EL2 (L0).
No, the instruction will have UNDEF in L2.
Furthermore, trapping non-matching CPUs is a guest decision, and L0 is
not in charge of deciding this. However, what is missing is the
redirection of the exception to L1 when it fires.
Something else to fix at some point.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-07-30 8:19 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 7:09 [PATCH v4 00/29] KVM: arm64: Add support for FEAT_NV2p1 and FEAT_NV3 Marc Zyngier
2026-07-30 7:09 ` [PATCH v4 01/29] arm64: sysreg: Emit RESx/UNKN values for Mapping/Fields definitions Marc Zyngier
2026-07-30 7:09 ` [PATCH v4 02/29] arm64: Update ID_AA64MMFR4_EL1 description to 2026-03 JSON release Marc Zyngier
2026-07-30 7:09 ` [PATCH v4 03/29] KVM: arm64: Merge guest's HCRX_EL2 using NV_HCRX_GUEST_EXCLUDE Marc Zyngier
2026-07-30 7:29 ` sashiko-bot
2026-07-30 8:01 ` Marc Zyngier [this message]
2026-07-30 7:09 ` [PATCH v4 04/29] KVM: arm64: Drop __HCRX_EL2_* masks Marc Zyngier
2026-07-30 7:09 ` [PATCH v4 05/29] KVM: arm64: Plumb HCRX_EL2.SRMASKEn in HCRX_EL2 sanitisation Marc Zyngier
2026-07-30 7:09 ` [PATCH v4 06/29] KVM: arm64: Classify CPTR_EL2 as a SR_LOC_SPECIAL register Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 07/29] KVM: arm64: Don't evaluate HCR_EL2.NV nor HFGITR_EL2.ERET on ERET fast path Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 08/29] arm64: Add ARM64_HAS_NV2P1 capability Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 09/29] KVM: arm64: Relax CPTR_EL2 handling when FEAT_NV2p1 is present Marc Zyngier
2026-07-30 7:56 ` sashiko-bot
2026-07-30 7:10 ` [PATCH v4 10/29] KVM: arm64: Relax CNTHCTL_EL2 " Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 11/29] KVM: arm64: Expose FEAT_NV2p1 to NV guests Marc Zyngier
2026-07-30 8:09 ` sashiko-bot
2026-07-30 7:10 ` [PATCH v4 12/29] arm64: Add FEAT_NV2p1 detection Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 13/29] arm64: sysreg: Add NVHCR_EL2 description as a mirror of HCR_EL2 Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 14/29] arm64: sysreg: Add HCRX_EL2 bits related to FEAT_NV3 Marc Zyngier
2026-07-30 7:40 ` sashiko-bot
2026-07-30 7:48 ` Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 15/29] arm64: Add ARM64_HAS_NV3 capability Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 16/29] KVM: arm64: Split NV-specific exit fixups from the non-NV handling Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 17/29] KVM: arm64: Add NV3 control bits to HCRX_EL2 sanitisation Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 18/29] KVM: arm64: Add kvm_has_nv{2,3}() predicates Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 19/29] KVM: arm64: Make HCR_EL2 a non-VNCR register Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 20/29] KVM: arm64: Add sanitisation for NVHCR_EL2 Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 21/29] KVM: arm64: Add NVHCR_EL2 handling to the sysreg array Marc Zyngier
2026-07-30 7:58 ` sashiko-bot
2026-07-30 7:10 ` [PATCH v4 22/29] KVM: arm64: Add routing for NVHCR_EL2 trap Marc Zyngier
2026-07-30 8:12 ` sashiko-bot
2026-07-30 7:10 ` [PATCH v4 23/29] KVM: arm64: Add NVHCR_EL2 context switching Marc Zyngier
2026-07-30 8:05 ` sashiko-bot
2026-07-30 7:10 ` [PATCH v4 24/29] KVM: arm64: Engage NV3 ERET trap elision Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 25/29] KVM: arm64: Engage NV3 TLBI " Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 26/29] KVM: arm64: Add FEAT_NV3 detection Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 27/29] KVM: arm64: Expose FEAT_NV3 to guests Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 28/29] KVM: arm64: selftest: Add NVHCR_EL2 to get-reg-list Marc Zyngier
2026-07-30 7:10 ` [PATCH v4 29/29] arm64: Add override for ID_AA64MMFR4_EL1.NV_frac Marc Zyngier
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=86o6fodhya.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=oupton@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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