[PATCH] KVM: arm64: Don't let a guest overwrite HCRX_EL2.MCE2

[PATCH] KVM: arm64: Don't let a guest overwrite HCRX_EL2.MCE2

[Marc Zyngier]

FEAT_MOPS is fun. CPUs are allowed to implement any of two ways to
perform the memory copy, and the hypervisor is in charge of hiding
the difference between implementation when the vcpu migrates from
one to another. This is unhelpfully signalled with an exception,
which KVM diligently handles.

Today, we don't really make a good job of it in the sense that
if L1 also has the trap bit set, we don't forward the trap as
the architecture would require us to do.

But there is no good reason to forward this to the L1 guest if
L2 generates the "I'm on the wrong implementation". KVM can fix
it up in place and return to L2 directly, as if the physical CPU
was able to implement both options.

Conversely, allowing L1 to clear HCRX_EL2.MCE2 is counter-productive,
and violates the abstraction that KVM aims to give.

Implement this behaviour by never allowing the guest's view of
HCRX_EL2.MCE2 to make it into the HW, and document that KVM is in
charge of the A/B handling.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/kvm/hyp/include/hyp/switch.h | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index a2a054fec2e2f..e18cf84a4993e 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -330,7 +330,7 @@ static inline void __deactivate_traps_mpam(void)
  * 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.
+ * guess). So it is always the guest inflicting it on its own guest.
  *
  * Things we don't want to let the guest control are:
  *
@@ -339,10 +339,14 @@ static inline void __deactivate_traps_mpam(void)
  * - PTTWI: Similarly, it is for us to decide whether Reduced Coherency for
  *   the PTW is a thing. It really isn't.
  *
+ * - MCE2: FEAT_MOPS generated exceptions for Option-{A,B} interoperability
+ *   are always handled on the host and not forwarded to a guest hypervisor
+ *   in order to give the (poor) illusion of a homogeneous system.
+ *
  * - EnIDCP128: We don't allow IMPDEF sysregs -- full stop.
  */
 #define NV_HCRX_GUEST_EXCLUDE	(HCRX_EL2_TMEA	    | HCRX_EL2_PTTWI | \
-				 HCRX_EL2_EnIDCP128)
+				 HCRX_EL2_MCE2	    | HCRX_EL2_EnIDCP128)
 
 static inline void __activate_traps_common(struct kvm_vcpu *vcpu)
 {
-- 
2.47.3

Re: [PATCH] KVM: arm64: Don't let a guest overwrite HCRX_EL2.MCE2

[Fuad Tabba]

On Mon, 26 Oct 2026 at 08:26, Marc Zyngier <maz@kernel.org> wrote:
>
> FEAT_MOPS is fun. CPUs are allowed to implement any of two ways to

It's a hoot! :)

> perform the memory copy, and the hypervisor is in charge of hiding
> the difference between implementation when the vcpu migrates from
> one to another. This is unhelpfully signalled with an exception,
> which KVM diligently handles.
>
> Today, we don't really make a good job of it in the sense that
> if L1 also has the trap bit set, we don't forward the trap as
> the architecture would require us to do.
>
> But there is no good reason to forward this to the L1 guest if
> L2 generates the "I'm on the wrong implementation". KVM can fix
> it up in place and return to L2 directly, as if the physical CPU
> was able to implement both options.
>
> Conversely, allowing L1 to clear HCRX_EL2.MCE2 is counter-productive,
> and violates the abstraction that KVM aims to give.
>
> Implement this behaviour by never allowing the guest's view of
> HCRX_EL2.MCE2 to make it into the HW, and document that KVM is in
> charge of the A/B handling.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>

Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>

Cheers,
/fuad

Re: [PATCH] KVM: arm64: Don't let a guest overwrite HCRX_EL2.MCE2

[Oliver Upton]

Hey,

On Mon, Oct 26, 2026 at 08:26:33AM +0000, Marc Zyngier wrote:
> FEAT_MOPS is fun. CPUs are allowed to implement any of two ways to
> perform the memory copy, and the hypervisor is in charge of hiding
> the difference between implementation when the vcpu migrates from
> one to another. This is unhelpfully signalled with an exception,
> which KVM diligently handles.
> 
> Today, we don't really make a good job of it in the sense that
> if L1 also has the trap bit set, we don't forward the trap as
> the architecture would require us to do.
> 
> But there is no good reason to forward this to the L1 guest if
> L2 generates the "I'm on the wrong implementation". KVM can fix
> it up in place and return to L2 directly, as if the physical CPU
> was able to implement both options.
> 
> Conversely, allowing L1 to clear HCRX_EL2.MCE2 is counter-productive,
> and violates the abstraction that KVM aims to give.

What abstraction? :-)

At least in the non-nested case we can blame the VMM since it's
responsible for scheduling vCPUs on the right pCPUs in a heterogeneous
system.

There is a subtlety here where if the VMM does the right thing with
sched affinities then a MOPS exception taken from L2 is definitely the
L1's fault and architecturally visible.

But oh well. We're obviously oriented towards presenting a homogeneous
set of vCPUs and anything else works by accident.

> Implement this behaviour by never allowing the guest's view of
> HCRX_EL2.MCE2 to make it into the HW, and document that KVM is in
> charge of the A/B handling.
> 
> Signed-off-by: Marc Zyngier <maz@kernel.org>

Reviewed-by: Oliver Upton <oupton@kernel.org>

Thanks,
Oliver

Re: [PATCH] KVM: arm64: Don't let a guest overwrite HCRX_EL2.MCE2

[Marc Zyngier]

On Wed, 28 Oct 2026 00:12:00 +0000,
Oliver Upton <oupton@kernel.org> wrote:
> 
> Hey,
> 
> On Mon, Oct 26, 2026 at 08:26:33AM +0000, Marc Zyngier wrote:
> > FEAT_MOPS is fun. CPUs are allowed to implement any of two ways to
> > perform the memory copy, and the hypervisor is in charge of hiding
> > the difference between implementation when the vcpu migrates from
> > one to another. This is unhelpfully signalled with an exception,
> > which KVM diligently handles.
> > 
> > Today, we don't really make a good job of it in the sense that
> > if L1 also has the trap bit set, we don't forward the trap as
> > the architecture would require us to do.
> > 
> > But there is no good reason to forward this to the L1 guest if
> > L2 generates the "I'm on the wrong implementation". KVM can fix
> > it up in place and return to L2 directly, as if the physical CPU
> > was able to implement both options.
> > 
> > Conversely, allowing L1 to clear HCRX_EL2.MCE2 is counter-productive,
> > and violates the abstraction that KVM aims to give.
> 
> What abstraction? :-)
> 
> At least in the non-nested case we can blame the VMM since it's
> responsible for scheduling vCPUs on the right pCPUs in a heterogeneous
> system.

The problem is that there is no ID register describing which
architectural option is implemented on a given CPU.

> There is a subtlety here where if the VMM does the right thing with
> sched affinities then a MOPS exception taken from L2 is definitely the
> L1's fault and architecturally visible.

How? It isn't discoverable the first place. And migration breaks this
entirely. The whole A/B thing is an absolute disaster.

> 
> But oh well. We're obviously oriented towards presenting a homogeneous
> set of vCPUs and anything else works by accident.
> 
> > Implement this behaviour by never allowing the guest's view of
> > HCRX_EL2.MCE2 to make it into the HW, and document that KVM is in
> > charge of the A/B handling.
> > 
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> 
> Reviewed-by: Oliver Upton <oupton@kernel.org>

Thanks!

	M.

-- 
Without deviation from the norm, progress is not possible.