From: Joey Gouly <joey.gouly@arm.com>
To: Fuad Tabba <tabba@google.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
maz@kernel.org, oliver.upton@linux.dev, will@kernel.org,
suzuki.poulose@arm.com, yuzenghui@huawei.com,
catalin.marinas@arm.com, vladimir.murzin@arm.com
Subject: Re: [PATCH v1 1/8] KVM: arm64: Route MOPS exceptions to EL2 when guest lacks support
Date: Tue, 4 Nov 2025 13:44:39 +0000 [thread overview]
Message-ID: <20251104134439.GA285975@e124191.cambridge.arm.com> (raw)
In-Reply-To: <20251104125906.1919426-2-tabba@google.com>
Hi Fuad,
On Tue, Nov 04, 2025 at 12:58:59PM +0000, Fuad Tabba wrote:
> MOPS exceptions must be routed to the hypervisor (EL2) when the guest
> does not support the feature. If the guest does support MOPS, exceptions
> should be handled by the guest at EL1.
>
> The existing logic was inverted: exceptions were trapped to EL2 (by
> setting HCRX_EL2_MCE2) when the guest supported MOPS, and left to be
> handled at EL1 when it did not.
>
This doesn't seem quite right? Check the commit message of 2de451a329:
A KVM guest may use the instructions at EL1 at times when the guest is
not able to handle the exception, expecting that the instructions will
only run on one CPU (e.g. when running UEFI boot services in the guest).
As KVM may reschedule the guest between different types of CPUs at any
time (on an asymmetric system), it needs to also handle the resulting
exception itself in case the guest is not able to. A similar situation
will also occur in the future when live migrating a guest from one type
of CPU to another.
So it's intentionally trapping MOPS to EL2.
Also with HCRX_EL2.MSCEn=0, execution of the MOPS instructions are UNDEFINED at
EL0/EL1, so you wouldn't take any MOPS exceptions to EL2 anyway.
Thanks,
Joey
> Fix this by moving the setting of HCRX_EL2_MCE2 from the feature-check
> block to the 'else' block, ensuring exceptions are only trapped to EL2
> when the guest cannot handle them.
>
> Fixes: 84de212d739e ("KVM: arm64: Make FEAT_MOPS UNDEF if not advertised to the guest")
> Signed-off-by: Fuad Tabba <tabba@google.com>
> ---
> arch/arm64/include/asm/kvm_emulate.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index c9eab316398e..0f8311263edf 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -684,7 +684,9 @@ static inline void vcpu_set_hcrx(struct kvm_vcpu *vcpu)
> vcpu->arch.hcrx_el2 = HCRX_EL2_SMPME;
>
> if (kvm_has_feat(kvm, ID_AA64ISAR2_EL1, MOPS, IMP))
> - vcpu->arch.hcrx_el2 |= (HCRX_EL2_MSCEn | HCRX_EL2_MCE2);
> + vcpu->arch.hcrx_el2 |= HCRX_EL2_MSCEn;
> + else
> + vcpu->arch.hcrx_el2 |= HCRX_EL2_MCE2;
>
> if (kvm_has_tcr2(kvm))
> vcpu->arch.hcrx_el2 |= HCRX_EL2_TCR2En;
> --
> 2.51.2.997.g839fc31de9-goog
>
next prev parent reply other threads:[~2025-11-04 13:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-04 12:58 [PATCH v1 0/8] KVM: arm64: Fixes for guest CPU feature trapping and enabling Fuad Tabba
2025-11-04 12:58 ` [PATCH v1 1/8] KVM: arm64: Route MOPS exceptions to EL2 when guest lacks support Fuad Tabba
2025-11-04 13:44 ` Joey Gouly [this message]
2025-11-04 13:49 ` Fuad Tabba
2025-11-04 12:59 ` [PATCH v1 2/8] KVM: arm64: Trap access to ALLINT if FEAT_NMI not supported by the guest Fuad Tabba
2025-11-04 15:15 ` Marc Zyngier
2025-11-04 15:30 ` Fuad Tabba
2025-11-04 17:22 ` Marc Zyngier
2025-11-04 17:30 ` Fuad Tabba
2025-11-04 12:59 ` [PATCH v1 3/8] KVM: arm64: Enable LS64 instructions when supported by guest Fuad Tabba
2025-11-04 15:26 ` Marc Zyngier
2025-11-04 15:31 ` Fuad Tabba
2025-11-04 12:59 ` [PATCH v1 4/8] KVM: arm64: Refactor vcpu_set_hcrx() to reduce indentation Fuad Tabba
2025-11-04 12:59 ` [PATCH v1 5/8] KVM: arm64: Fix Trace Buffer trap polarity for protected VMs Fuad Tabba
2025-11-04 17:50 ` Suzuki K Poulose
2025-11-04 17:56 ` Fuad Tabba
2025-11-04 18:03 ` Suzuki K Poulose
2025-11-04 19:04 ` Fuad Tabba
2025-11-04 12:59 ` [PATCH v1 6/8] KVM: arm64: Fix MTE flag initialization " Fuad Tabba
2025-11-04 12:59 ` [PATCH v1 7/8] KVM: arm64: Prevent host from managing timer offsets " Fuad Tabba
2025-11-04 12:59 ` [PATCH v1 8/8] KVM: arm64: Define FAR_MASK for faulting IPA offset 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=20251104134439.GA285975@e124191.cambridge.arm.com \
--to=joey.gouly@arm.com \
--cc=catalin.marinas@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=vladimir.murzin@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).