From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C67DDD2D0EA for ; Tue, 13 Jan 2026 12:48:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=GBn4vzxGDGOP8vN0eGuN0F1an9awLjoq1I6ZyMzSguc=; b=XQQeJoLoIXh5QIw4hrosw6RWf0 jYzZgvINiSrNjjC1Qv1DpG+XTL3ZL/cVUTnm12F4Fad2MsceZ7uSaBYxdK7Vt47CS5krgljToMKXD 6zSI3Uuz7PeAe1cRXRLAVtUh6kbFi8uvdr4Ne1iUM2/cdkD5BKbJ0YDdyJSCaG13BewHiVF5i6Sj5 865a3xNy/Ui9k0g6v1BgODhgGyF0vU2nWJaKduRSns3KAom//2uSotzdJcbCyp3PtdBR38pCLTJqC iuF52y0BMsO2VtsDSayvkniRMj2moPSyv6LpnHVMrH1eSgZY2OeR4oAirc3vtCzhHNf8JC8Er3arK jPaOpmTw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vfdp4-000000077Fq-1qx6; Tue, 13 Jan 2026 12:48:36 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vfdp1-000000077FE-3pkB for linux-arm-kernel@lists.infradead.org; Tue, 13 Jan 2026 12:48:33 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5932A497; Tue, 13 Jan 2026 04:48:22 -0800 (PST) Received: from raptor (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 462EE3F59E; Tue, 13 Jan 2026 04:48:27 -0800 (PST) Date: Tue, 13 Jan 2026 12:48:24 +0000 From: Alexandru Elisei To: James Clark Cc: mark.rutland@arm.com, james.morse@arm.com, maz@kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, will@kernel.org, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [RFC PATCH v6 19/35] KVM: arm64: Trap PMBIDR_EL1 and PMSIDR_EL1 Message-ID: References: <20251114160717.163230-1-alexandru.elisei@arm.com> <20251114160717.163230-20-alexandru.elisei@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260113_044832_044727_048C6EB2 X-CRM114-Status: GOOD ( 37.70 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi James, On Mon, Jan 12, 2026 at 11:54:05AM +0000, James Clark wrote: > > > On 12/01/2026 11:28 am, Alexandru Elisei wrote: > > Hi James, > > > > On Fri, Jan 09, 2026 at 04:29:37PM +0000, James Clark wrote: > > > > > > > > > On 14/11/2025 4:07 pm, Alexandru Elisei wrote: > > > > PMBIDR_EL1 and PMSIDR_EL1 are read-only registers that describe the SPE > > > > implementation. Trap reads to allow KVM to control how SPE is described to > > > > a virtual machine. In particular, this is needed to: > > > > > > > > - Advertise the maximum buffer size set by userspace in > > > > PMBIDR_EL1.MaxBuffSize. > > > > - Hide in PMSIDR_EL1, if necessary, the presence of FEAT_SPE_FDS and > > > > FEAT_SPE_FnE, both of which add new registers which are already > > > > trapped via the FGU mechanism. > > > > > > > > Signed-off-by: Alexandru Elisei > > > > --- > > > > arch/arm64/include/asm/kvm_spe.h | 4 +- > > > > arch/arm64/kvm/config.c | 13 ++++- > > > > arch/arm64/kvm/spe.c | 82 +++++++++++++++++++++++++++++++- > > > > arch/arm64/kvm/sys_regs.c | 13 +++-- > > > > 4 files changed, 103 insertions(+), 9 deletions(-) > > > > > > > > diff --git a/arch/arm64/include/asm/kvm_spe.h b/arch/arm64/include/asm/kvm_spe.h > > > > index 3506d8c4c661..47b94794cc5f 100644 > > > > --- a/arch/arm64/include/asm/kvm_spe.h > > > > +++ b/arch/arm64/include/asm/kvm_spe.h > > > > @@ -40,7 +40,7 @@ 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); > > > > bool kvm_spe_write_sysreg(struct kvm_vcpu *vcpu, int reg, u64 val); > > > > -u64 kvm_spe_read_sysreg(struct kvm_vcpu *vcpu, int reg); > > > > +u64 kvm_spe_read_sysreg(struct kvm_vcpu *vcpu, int reg, u32 encoding); > > > > #else > > > > struct kvm_spe { > > > > }; > > > > @@ -78,7 +78,7 @@ static inline bool kvm_spe_write_sysreg(struct kvm_vcpu *vcpu, int reg, u64 val) > > > > { > > > > return true; > > > > } > > > > -static inline u64 kvm_spe_read_sysreg(struct kvm_vcpu *vcpu, int reg) > > > > +static inline u64 kvm_spe_read_sysreg(struct kvm_vcpu *vcpu, int reg, u32 encoding) > > > > { > > > > return 0; > > > > } > > > > diff --git a/arch/arm64/kvm/config.c b/arch/arm64/kvm/config.c > > > > index 24bb3f36e9d5..ed6b167b7aa8 100644 > > > > --- a/arch/arm64/kvm/config.c > > > > +++ b/arch/arm64/kvm/config.c > > > > @@ -6,6 +6,7 @@ > > > > #include > > > > #include > > > > +#include > > > > #include > > > > #include > > > > @@ -1489,6 +1490,16 @@ static void __compute_hfgwtr(struct kvm_vcpu *vcpu) > > > > *vcpu_fgt(vcpu, HFGWTR_EL2) |= HFGWTR_EL2_TCR_EL1; > > > > } > > > > +static void __compute_hdfgrtr(struct kvm_vcpu *vcpu) > > > > +{ > > > > + __compute_fgt(vcpu, HDFGRTR_EL2); > > > > + > > > > + if (vcpu_has_spe(vcpu)) { > > > > + *vcpu_fgt(vcpu, HDFGRTR_EL2) |= HDFGRTR_EL2_PMBIDR_EL1; > > > > + *vcpu_fgt(vcpu, HDFGRTR_EL2) |= HDFGRTR_EL2_PMSIDR_EL1; > > > > + } > > > > +} > > > > + > > > > static void __compute_hdfgwtr(struct kvm_vcpu *vcpu) > > > > { > > > > __compute_fgt(vcpu, HDFGWTR_EL2); > > > > @@ -1505,7 +1516,7 @@ void kvm_vcpu_load_fgt(struct kvm_vcpu *vcpu) > > > > __compute_fgt(vcpu, HFGRTR_EL2); > > > > __compute_hfgwtr(vcpu); > > > > __compute_fgt(vcpu, HFGITR_EL2); > > > > - __compute_fgt(vcpu, HDFGRTR_EL2); > > > > + __compute_hdfgrtr(vcpu); > > > > __compute_hdfgwtr(vcpu); > > > > __compute_fgt(vcpu, HAFGRTR_EL2); > > > > diff --git a/arch/arm64/kvm/spe.c b/arch/arm64/kvm/spe.c > > > > index 5b3dc622cf82..92eb46276c71 100644 > > > > --- a/arch/arm64/kvm/spe.c > > > > +++ b/arch/arm64/kvm/spe.c > > > > @@ -22,10 +22,16 @@ struct arm_spu_entry { > > > > struct arm_spe_pmu *arm_spu; > > > > }; > > > > +static u64 max_buffer_size_to_pmbidr_el1(u64 size); > > > > + > > > > void kvm_host_spe_init(struct arm_spe_pmu *arm_spu) > > > > { > > > > struct arm_spu_entry *entry; > > > > + /* PMBIDR_EL1 cannot be trapped without FEAT_FGT. */ > > > > + if (!cpus_have_final_cap(ARM64_HAS_FGT)) > > > > + return; > > > > + > > > > > > Isn't this only required if you want to report a different PMBIDR value? If > > > the value in hardware is already what you want to give to guests then it's > > > not strictly required. Maybe it's something we can do as an addition later > > > to make it usable in more places. > > > > The maximum buffer size is advertised in PMBIDR_EL1. > > > > Thanks, > > Alex > > > > I know, but 0 "unlimited" is a valid value, and that's what's already in > PMBIDR. You only need to trap if the value doesn't match what's already > there. > > You can also "probe" the maximum buffer size without this by attempting to > set the limit pointer and looking at the buffer management error code. > > The first thing I did when I went to use this was comment this out because > my hardware doesn't support FGT. But the rest of it works fine without, > maybe other people could benefit in the future too. I could add a new capability for setting the maximum buffer size (or to set a buffer size different than what the hardware advertises), enabled when FEAT_FGT is implement by the hardware. But that means not allowing KVM SPE on Neoverse because of erratum 3023823 [1]. So I don't think you would be able to use KVM SPE out of the box on your hardware anyway (if I understood correctly that you've been using a Neoverse CPU to test the series). [1] https://developer.arm.com/documentation/SDEN-885747/34-0 Thanks, Alex