From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>,
Joey Gouly <joey.gouly@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Will Deacon <will@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Jonathan Corbet <corbet@lwn.net>, Shuah Khan <shuah@kernel.org>,
Dave Martin <Dave.Martin@arm.com>, Fuad Tabba <tabba@google.com>,
Mark Rutland <mark.rutland@arm.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
Peter Maydell <peter.maydell@linaro.org>,
Eric Auger <eric.auger@redhat.com>
Subject: Re: [PATCH v8 06/29] KVM: arm64: Introduce non-UNDEF FGT control
Date: Fri, 19 Sep 2025 16:14:49 +0100 [thread overview]
Message-ID: <87zfaqxymu.wl-maz@kernel.org> (raw)
In-Reply-To: <20250902-kvm-arm64-sme-v8-6-2cb2199c656c@kernel.org>
On Tue, 02 Sep 2025 12:36:09 +0100,
Mark Brown <broonie@kernel.org> wrote:
>
> We have support for determining a set of fine grained traps to enable for
> the guest which is tied to the support for injecting UNDEFs for undefined
> features. This means that we can't use the mechanism for system registers
> which should be present but need emulation, such as SMPRI_EL1 which should
> be accessible when SME is present but if SME priority support is absent
> SMPRI_EL1.Priority should be RAZ.
>
> Add an additional set of fine grained traps fgt, mirroring the existing fgu
> array. We use the same format where we always set the bit for the trap in
> the array as for FGU. This makes it clear what is being explicitly managed
> and keeps the code consistent.
>
> We do not convert the handling of ARM_WORKAROUND_AMPERE_ACO3_CPU_38 to this
> mechanism since this only enables a write trap and when implementing the
> existing UNDEF that we would share the read and write trap enablement (this
> being the overwhelmingly common case).
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> arch/arm64/include/asm/kvm_host.h | 6 ++++++
> arch/arm64/kvm/hyp/include/hyp/switch.h | 7 ++++---
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 2f2394cce24e..b501c2880ba2 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -302,6 +302,12 @@ struct kvm_arch {
> */
> u64 fgu[__NR_FGT_GROUP_IDS__];
>
> + /*
> + * Additional FGTs to enable for the guests, eg. for emulated
> + * registers,
> + */
> + u64 fgt[__NR_FGT_GROUP_IDS__];
> +
Conceptually, this serves the same role as the existing control
registers (HCR_EL2, HCRX_EL2, MDCR_EL2), which are obviously
per-vcpu. So having this on a per-VM basis doesn't really work,
because we definitely don't expect this to be uniform (see
20250917203125.283116-3-oliver.upton@linux.dev for an example of why
this is not the case).
FGUs are uniform, because when something doesn't exist on a vcpu, it
doesn't exist on *any* vcpu. Non-FGU use of FGTs, however, has to be
more flexible because that's part of the emulation, and is actually
pretty rare that we want to trap something at all times, on all vcpus.
For the same reason, conflating the R and W registers doesn't work
either. For the above example, I want to be able to trap write
accesses to MDSCR_EL1, and not reads, just like the Ampere
brain-damage.
So please make this per-vcpu, decouple R and W FGTs, and convert the
Ampere horror to this scheme.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
next prev parent reply other threads:[~2025-09-19 15:14 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 11:36 [PATCH v8 00/29] KVM: arm64: Implement support for SME Mark Brown
2025-09-02 11:36 ` [PATCH v8 01/29] arm64/sysreg: Update SMIDR_EL1 to DDI0601 2025-06 Mark Brown
2025-09-02 11:36 ` [PATCH v8 02/29] arm64/fpsimd: Update FA64 and ZT0 enables when loading SME state Mark Brown
2025-09-02 11:36 ` [PATCH v8 03/29] arm64/fpsimd: Decide to save ZT0 and streaming mode FFR at bind time Mark Brown
2025-09-02 11:36 ` [PATCH v8 04/29] arm64/fpsimd: Check enable bit for FA64 when saving EFI state Mark Brown
2025-09-02 11:36 ` [PATCH v8 05/29] arm64/fpsimd: Determine maximum virtualisable SME vector length Mark Brown
2025-09-02 11:36 ` [PATCH v8 06/29] KVM: arm64: Introduce non-UNDEF FGT control Mark Brown
2025-09-19 15:14 ` Marc Zyngier [this message]
2025-09-19 15:53 ` Mark Brown
2025-09-02 11:36 ` [PATCH v8 07/29] KVM: arm64: Pay attention to FFR parameter in SVE save and load Mark Brown
2025-09-02 11:36 ` [PATCH v8 08/29] KVM: arm64: Pull ctxt_has_ helpers to start of sysreg-sr.h Mark Brown
2025-09-02 11:36 ` [PATCH v8 09/29] KVM: arm64: Move SVE state access macros after feature test macros Mark Brown
2025-09-02 11:36 ` [PATCH v8 10/29] KVM: arm64: Rename SVE finalization constants to be more general Mark Brown
2025-09-02 11:36 ` [PATCH v8 11/29] KVM: arm64: Document the KVM ABI for SME Mark Brown
2025-09-02 11:36 ` [PATCH v8 12/29] KVM: arm64: Define internal features " Mark Brown
2025-09-02 11:36 ` [PATCH v8 13/29] KVM: arm64: Rename sve_state_reg_region Mark Brown
2025-09-02 11:36 ` [PATCH v8 14/29] KVM: arm64: Store vector lengths in an array Mark Brown
2025-09-02 11:36 ` [PATCH v8 15/29] KVM: arm64: Implement SME vector length configuration Mark Brown
2025-09-02 11:36 ` [PATCH v8 16/29] KVM: arm64: Support SME control registers Mark Brown
2025-09-02 11:36 ` [PATCH v8 17/29] KVM: arm64: Support TPIDR2_EL0 Mark Brown
2025-09-02 11:36 ` [PATCH v8 18/29] KVM: arm64: Support SME identification registers for guests Mark Brown
2025-09-02 11:36 ` [PATCH v8 19/29] KVM: arm64: Support SME priority registers Mark Brown
2025-09-02 11:36 ` [PATCH v8 20/29] KVM: arm64: Provide assembly for SME register access Mark Brown
2025-09-02 11:36 ` [PATCH v8 21/29] KVM: arm64: Support userspace access to streaming mode Z and P registers Mark Brown
2025-09-02 11:36 ` [PATCH v8 22/29] KVM: arm64: Flush register state on writes to SVCR.SM and SVCR.ZA Mark Brown
2025-09-02 11:36 ` [PATCH v8 23/29] KVM: arm64: Expose SME specific state to userspace Mark Brown
2025-09-02 11:36 ` [PATCH v8 24/29] KVM: arm64: Context switch SME state for guests Mark Brown
2025-09-02 11:36 ` [PATCH v8 25/29] KVM: arm64: Handle SME exceptions Mark Brown
2025-09-02 11:36 ` [PATCH v8 26/29] KVM: arm64: Expose SME to nested guests Mark Brown
2025-09-02 11:36 ` [PATCH v8 27/29] KVM: arm64: Provide interface for configuring and enabling SME for guests Mark Brown
2025-09-02 11:36 ` [PATCH v8 28/29] KVM: arm64: selftests: Add SME system registers to get-reg-list Mark Brown
2025-09-02 11:36 ` [PATCH v8 29/29] KVM: arm64: selftests: Add SME to set_id_regs test Mark Brown
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=87zfaqxymu.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=Dave.Martin@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=eric.auger@redhat.com \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=shuah@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
/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).