From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oupton@kernel.org>
Cc: kvmarm@lists.linux.dev, Steffen Eiden <seiden@linux.ibm.com>,
Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Fuad Tabba <fuad.tabba@linux.dev>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH] KVM: arm64: Don't let a guest overwrite HCRX_EL2.MCE2
Date: Wed, 28 Oct 2026 09:38:58 +0000 [thread overview]
Message-ID: <86o6cexiz1.wl-maz@kernel.org> (raw)
In-Reply-To: <auE90LmMMmac8J1s@kernel.org>
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.
prev parent reply other threads:[~2026-10-28 9:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 8:26 [PATCH] KVM: arm64: Don't let a guest overwrite HCRX_EL2.MCE2 Marc Zyngier
2026-10-26 11:50 ` Fuad Tabba
2026-10-28 0:12 ` Oliver Upton
2026-10-28 9:38 ` Marc Zyngier [this message]
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=86o6cexiz1.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=fuad.tabba@linux.dev \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=oupton@kernel.org \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--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.