From: Alexandru Elisei <alexandru.elisei@arm.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: maz@kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com,
yuzenghui@huawei.com, will@kernel.org, catalin.marinas@arm.com,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
james.clark@linaro.org, mark.rutland@arm.com,
james.morse@arm.com
Subject: Re: [RFC PATCH v6 16/35] KVM: arm64: Advertise SPE version in ID_AA64DFR0_EL1.PMSver
Date: Mon, 5 Jan 2026 16:42:09 +0000 [thread overview]
Message-ID: <aVvppjU3OXXIcJIo@raptor> (raw)
In-Reply-To: <36416368-4447-4b16-8496-3e3d603d88d4@arm.com>
Hi Suzuki,
Thanks for having a look.
On Tue, Dec 16, 2025 at 11:40:20AM +0000, Suzuki K Poulose wrote:
> On 14/11/2025 16:06, Alexandru Elisei wrote:
> > The VCPU registers are reset during the KVM_ARM_VCPU_INIT ioctl, before
> > userspace can set the desired SPU. Assume that the VCPU is initialized from
>
>
> > a thread that runs on one of the physical CPUs that correspond to the SPU
> > that userspace will choose for the VM. Set PMSVer to that CPUs hardware
> > value.
>
> This doesn't match the code. See below.
Indeed.
>
> >
> > Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> > ---
> > arch/arm64/include/asm/kvm_spe.h | 6 ++++++
> > arch/arm64/kvm/spe.c | 10 ++++++++++
> > arch/arm64/kvm/sys_regs.c | 10 +++++++++-
> > 3 files changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_spe.h b/arch/arm64/include/asm/kvm_spe.h
> > index 6ce70cf2abaf..5e6d7e609a48 100644
> > --- a/arch/arm64/include/asm/kvm_spe.h
> > +++ b/arch/arm64/include/asm/kvm_spe.h
> > @@ -33,6 +33,8 @@ static __always_inline bool kvm_supports_spe(void)
> > void kvm_spe_init_vm(struct kvm *kvm);
> > int kvm_spe_vcpu_first_run_init(struct kvm_vcpu *vcpu);
> > +u8 kvm_spe_get_pmsver_limit(void);
> > +
> > int kvm_spe_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr);
> > int kvm_spe_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr);
> > int kvm_spe_has_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr);
> > @@ -53,6 +55,10 @@ static inline int kvm_spe_vcpu_first_run_init(struct kvm_vcpu *vcpu)
> > {
> > return 0;
> > }
> > +static inline u8 kvm_spe_get_pmsver_limit(void)
> > +{
> > + return 0;
> > +}
> > static inline int kvm_spe_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
> > {
> > return -ENXIO;
> > diff --git a/arch/arm64/kvm/spe.c b/arch/arm64/kvm/spe.c
> > index 6bd074e40f6c..0c4896c6a873 100644
> > --- a/arch/arm64/kvm/spe.c
> > +++ b/arch/arm64/kvm/spe.c
> > @@ -68,6 +68,16 @@ int kvm_spe_vcpu_first_run_init(struct kvm_vcpu *vcpu)
> > return 0;
> > }
> > +u8 kvm_spe_get_pmsver_limit(void)
> > +{
> > + unsigned int pmsver;
> > +
> > + pmsver = SYS_FIELD_GET(ID_AA64DFR0_EL1, PMSVer,
> > + read_sanitised_ftr_reg(SYS_ID_AA64DFR0_EL1));
>
> The read_sanitised_ftr_reg() gives you the system wide sanitised
> version, not the one on the current CPU. You may need
> read_sysreg_s() instead here.
Yes.
>
>
> > +
> > + return min(pmsver, ID_AA64DFR0_EL1_PMSVer_V1P5);
> > +}
> > +
> > static u64 max_buffer_size_to_pmbidr_el1(u64 size)
> > {
> > u64 msb_idx, num_bits;
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index e67eb39ddc11..ac859c39c2be 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -29,6 +29,7 @@
> > #include <asm/kvm_hyp.h>
> > #include <asm/kvm_mmu.h>
> > #include <asm/kvm_nested.h>
> > +#include <asm/kvm_spe.h>
> > #include <asm/perf_event.h>
> > #include <asm/sysreg.h>
> > @@ -1652,6 +1653,9 @@ static s64 kvm_arm64_ftr_safe_value(u32 id, const struct arm64_ftr_bits *ftrp,
> > case ID_AA64DFR0_EL1_DebugVer_SHIFT:
> > kvm_ftr.type = FTR_LOWER_SAFE;
> > break;
> > + case ID_AA64DFR0_EL1_PMSVer_SHIFT:
> > + kvm_ftr.type = FTR_LOWER_SAFE;
>
> PMSVer is already FTR_LOWER_SAFE, and we don't need to override it here ?
> (unlike the DebugVer or PMU Ver)
Don't need to override it, yes, didn't realize that it's FTR_LOWER_SAFE in
cpufeature.c when I wrote this.
>
> > + break;
> > }
> > break;
> > case SYS_ID_DFR0_EL1:
> > @@ -2021,8 +2025,11 @@ static u64 sanitise_id_aa64dfr0_el1(const struct kvm_vcpu *vcpu, u64 val)
> > val |= SYS_FIELD_PREP(ID_AA64DFR0_EL1, PMUVer,
> > kvm_arm_pmu_get_pmuver_limit());
> > - /* Hide SPE from guests */
> > val &= ~ID_AA64DFR0_EL1_PMSVer_MASK;
> > + if (vcpu_has_spe(vcpu)) {
> > + val |= SYS_FIELD_PREP(ID_AA64DFR0_EL1, PMSVer,
> > + kvm_spe_get_pmsver_limit());
> > + }
>
> So, we ignore value that the user sets and go with what the SPE instance
> that has been chosen ? Should we make it non-writable then ?
I modelled this after how PMUVer is handled, though that's not an excuse for
getting it wrong. My intention was to limit the maximum version that userspace
can set to the version of the SPU assigned to the VM.
But now that I think about it, some SPE versions introduce new fields in a
record, and there's no way for KVM to hide that if userspace set a lower version
for the VM. So I guess for now I'll not allow userspace to write PMSVer and
revisit it if someone wants it.
Thanks,
Alex
next prev parent reply other threads:[~2026-01-05 16:42 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-14 16:06 [RFC PATCH v6 00/35] KVM: arm64: Add Statistical Profiling Extension (SPE) support Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 01/35] arm64/sysreg: Add new SPE fields Alexandru Elisei
2025-12-10 18:38 ` Leo Yan
2025-12-12 9:39 ` Alexandru Elisei
2025-12-15 21:42 ` Suzuki K Poulose
2025-11-14 16:06 ` [RFC PATCH v6 02/35] arm64/sysreg: Define MDCR_EL2.E2PB values Alexandru Elisei
2025-12-15 21:33 ` Suzuki K Poulose
2025-11-14 16:06 ` [RFC PATCH v6 03/35] KVM: arm64: Add CONFIG_KVM_ARM_SPE Kconfig option Alexandru Elisei
2026-01-09 16:29 ` James Clark
2026-01-12 11:26 ` Alexandru Elisei
2026-01-12 12:09 ` James Clark
2026-01-12 12:14 ` James Clark
2026-01-12 15:18 ` Alexandru Elisei
2026-01-13 10:25 ` Alexandru Elisei
2026-01-13 15:00 ` James Clark
2026-01-13 17:03 ` Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 04/35] perf: arm_spe_pmu: Move struct arm_spe_pmu to a separate header file Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 05/35] KVM: arm64: Add KVM_CAP_ARM_SPE capability Alexandru Elisei
2025-12-14 12:18 ` Leo Yan
2025-12-15 11:46 ` Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 06/35] KVM: arm64: Add KVM_ARM_VCPU_SPE VCPU feature Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 07/35] HACK! KVM: arm64: Disable SPE virtualization if protected KVM is enabled Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 08/35] HACK! KVM: arm64: Enable SPE virtualization only in VHE mode Alexandru Elisei
2025-12-15 17:49 ` Leo Yan
2025-11-14 16:06 ` [RFC PATCH v6 09/35] HACK! KVM: arm64: Disable SPE virtualization if nested virt is enabled Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 10/35] KVM: arm64: Add a new VCPU device control group for SPE Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 11/35] KVM: arm64: Add SPE VCPU device attribute to set the interrupt number Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 12/35] KVM: arm64: Add SPE VCPU device attribute to set the SPU device Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 13/35] perf: arm_spe_pmu: Add PMBIDR_EL1 to struct arm_spe_pmu Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 14/35] KVM: arm64: Add SPE VCPU device attribute to set the max buffer size Alexandru Elisei
2026-01-09 16:29 ` James Clark
2026-01-12 11:28 ` Alexandru Elisei
2026-01-12 11:50 ` James Clark
2026-01-12 14:03 ` Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 15/35] KVM: arm64: Add SPE VCPU device attribute to initialize SPE Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 16/35] KVM: arm64: Advertise SPE version in ID_AA64DFR0_EL1.PMSver Alexandru Elisei
2025-12-16 11:40 ` Suzuki K Poulose
2026-01-05 16:42 ` Alexandru Elisei [this message]
2025-11-14 16:06 ` [RFC PATCH v6 17/35] KVM: arm64: Add writable SPE system registers to VCPU context Alexandru Elisei
2025-12-16 11:54 ` Suzuki K Poulose
2026-01-05 16:42 ` Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 18/35] perf: arm_spe_pmu: Add PMSIDR_EL1 to struct arm_spe_pmu Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 19/35] KVM: arm64: Trap PMBIDR_EL1 and PMSIDR_EL1 Alexandru Elisei
2026-01-09 16:29 ` James Clark
2026-01-12 11:28 ` Alexandru Elisei
2026-01-12 11:54 ` James Clark
2026-01-13 12:48 ` Alexandru Elisei
2026-01-13 14:22 ` James Clark
2025-11-14 16:07 ` [RFC PATCH v6 20/35] KVM: arm64: config: Use functions from spe.c to test FEAT_SPE_{FnE,FDS} Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 21/35] KVM: arm64: Check for unsupported CPU early in kvm_arch_vcpu_load() Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 22/35] KVM: arm64: VHE: Context switch SPE state Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 23/35] KVM: arm64: Allow guest SPE physical timestamps only if perfmon_capable() Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 24/35] KVM: arm64: Handle SPE hardware maintenance interrupts Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 25/35] KVM: arm64: Add basic handling of SPE buffer control registers writes Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 26/35] KVM: arm64: Add comment to explain how trapped SPE registers are handled Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 27/35] KVM: arm64: Make MTE functions public Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 28/35] KVM: arm64: at: Use callback for reading descriptor Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 29/35] KVM: arm64: Pin the SPE buffer in the host and map it at stage 2 Alexandru Elisei
2026-01-09 16:29 ` James Clark
2026-01-09 16:35 ` James Clark
2026-01-12 12:01 ` Alexandru Elisei
2026-01-13 14:18 ` James Clark
2025-11-14 16:07 ` [RFC PATCH v6 30/35] KVM: Propagate MMU event to the MMU notifier handlers Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 31/35] KVM: arm64: Handle MMU notifiers for the SPE buffer Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 32/35] KVM: Add KVM_EXIT_RLIMIT exit_reason Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 33/35] KVM: arm64: Implement locked memory accounting for the SPE buffer Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 34/35] KVM: arm64: Add hugetlb support for SPE Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 35/35] KVM: arm64: Allow the creation of a SPE enabled VM Alexandru Elisei
2025-12-11 16:34 ` [RFC PATCH v6 00/35] KVM: arm64: Add Statistical Profiling Extension (SPE) support Leo Yan
2025-12-12 10:18 ` Alexandru Elisei
2025-12-12 11:15 ` Leo Yan
2025-12-12 11:54 ` Alexandru Elisei
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=aVvppjU3OXXIcJIo@raptor \
--to=alexandru.elisei@arm.com \
--cc=catalin.marinas@arm.com \
--cc=james.clark@linaro.org \
--cc=james.morse@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@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