From: Marc Zyngier <maz@kernel.org>
To: Joey Gouly <joey.gouly@arm.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
kvm@vger.kernel.org, James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>, Fuad Tabba <tabba@google.com>,
Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH v3 8/8] KVM: arm64: Expose ID_AA64PFR2_EL1 to userspace and guests
Date: Tue, 13 Aug 2024 13:47:48 +0100 [thread overview]
Message-ID: <86y150zj0r.wl-maz@kernel.org> (raw)
In-Reply-To: <20240813105710.GA3154421@e124191.cambridge.arm.com>
On Tue, 13 Aug 2024 11:57:10 +0100,
Joey Gouly <joey.gouly@arm.com> wrote:
>
> Hello!
>
> On Tue, Aug 13, 2024 at 11:44:00AM +0100, Marc Zyngier wrote:
> > Everything is now in place for a guest to "enjoy" FP8 support.
> > Expose ID_AA64PFR2_EL1 to both userspace and guests, with the
> > explicit restriction of only being able to clear FPMR.
> >
> > All other features (MTE* at the time of writing) are hidden
> > and not writable.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kvm/sys_regs.c | 16 +++++++++++++++-
> > 1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index 51627add0a72..da6d017f24a1 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -1722,6 +1722,15 @@ static u64 read_sanitised_id_aa64pfr0_el1(struct kvm_vcpu *vcpu,
> > return val;
> > }
> >
> > +static u64 read_sanitised_id_aa64pfr2_el1(struct kvm_vcpu *vcpu,
> > + const struct sys_reg_desc *rd)
> > +{
> > + u64 val = read_sanitised_ftr_reg(SYS_ID_AA64PFR2_EL1);
> > +
> > + /* We only expose FPMR */
> > + return val & ID_AA64PFR2_EL1_FPMR;
> > +}
>
> Wondering why you're adding this function instead of extending __kvm_read_sanitised_id_reg()?
>
> > +
> > #define ID_REG_LIMIT_FIELD_ENUM(val, reg, field, limit) \
> > ({ \
> > u64 __f_val = FIELD_GET(reg##_##field##_MASK, val); \
> > @@ -2381,7 +2390,12 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> > ID_AA64PFR0_EL1_AdvSIMD |
> > ID_AA64PFR0_EL1_FP), },
> > ID_SANITISED(ID_AA64PFR1_EL1),
> > - ID_UNALLOCATED(4,2),
> > + { SYS_DESC(SYS_ID_AA64PFR2_EL1),
> > + .access = access_id_reg,
> > + .get_user = get_id_reg,
> > + .set_user = set_id_reg,
> > + .reset = read_sanitised_id_aa64pfr2_el1,
> > + .val = ID_AA64PFR2_EL1_FPMR, },
>
> Then I think this would just be ID_WRITABLE(ID_AA64PFR2_EL1, ID_AA64PFR2_EL1_FPMR).
Yeah, that's an interesting point. I'm afraid I have lost track of the
many helpers that have been added over time.
Something like this?
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index da6d017f24a1..2d1e45178422 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1539,6 +1539,10 @@ static u64 __kvm_read_sanitised_id_reg(const struct kvm_vcpu *vcpu,
val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_SME);
break;
+ case SYS_ID_AA64PFR2_EL1:
+ /* We only expose FPMR */
+ val &= ID_AA64PFR2_EL1_FPMR;
+ break;
case SYS_ID_AA64ISAR1_EL1:
if (!vcpu_has_ptrauth(vcpu))
val &= ~(ARM64_FEATURE_MASK(ID_AA64ISAR1_EL1_APA) |
@@ -1722,15 +1726,6 @@ static u64 read_sanitised_id_aa64pfr0_el1(struct kvm_vcpu *vcpu,
return val;
}
-static u64 read_sanitised_id_aa64pfr2_el1(struct kvm_vcpu *vcpu,
- const struct sys_reg_desc *rd)
-{
- u64 val = read_sanitised_ftr_reg(SYS_ID_AA64PFR2_EL1);
-
- /* We only expose FPMR */
- return val & ID_AA64PFR2_EL1_FPMR;
-}
-
#define ID_REG_LIMIT_FIELD_ENUM(val, reg, field, limit) \
({ \
u64 __f_val = FIELD_GET(reg##_##field##_MASK, val); \
@@ -2390,12 +2385,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
ID_AA64PFR0_EL1_AdvSIMD |
ID_AA64PFR0_EL1_FP), },
ID_SANITISED(ID_AA64PFR1_EL1),
- { SYS_DESC(SYS_ID_AA64PFR2_EL1),
- .access = access_id_reg,
- .get_user = get_id_reg,
- .set_user = set_id_reg,
- .reset = read_sanitised_id_aa64pfr2_el1,
- .val = ID_AA64PFR2_EL1_FPMR, },
+ ID_WRITABLE(ID_AA64PFR2_EL1, ID_AA64PFR2_EL1_FPMR),
ID_UNALLOCATED(4,3),
ID_WRITABLE(ID_AA64ZFR0_EL1, ~ID_AA64ZFR0_EL1_RES0),
ID_HIDDEN(ID_AA64SMFR0_EL1),
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-08-13 12:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-13 10:43 [PATCH v3 0/8] KVM: arm64: Add support for FP8 Marc Zyngier
2024-08-13 10:43 ` [PATCH v3 1/8] KVM: arm64: Move SVCR into the sysreg array Marc Zyngier
2024-08-13 10:43 ` [PATCH v3 2/8] KVM: arm64: Add predicate for FPMR support in a VM Marc Zyngier
2024-08-13 10:43 ` [PATCH v3 3/8] KVM: arm64: Move FPMR into the sysreg array Marc Zyngier
2024-08-13 10:43 ` [PATCH v3 4/8] KVM: arm64: Add save/restore support for FPMR Marc Zyngier
2024-08-13 10:43 ` [PATCH v3 5/8] KVM: arm64: Honor trap routing " Marc Zyngier
2024-08-13 10:43 ` [PATCH v3 6/8] KVM: arm64: Expose ID_AA64FPFR0_EL1 as a writable ID reg Marc Zyngier
2024-08-13 10:43 ` [PATCH v3 7/8] KVM: arm64: Enable FP8 support when available and configured Marc Zyngier
2024-08-13 10:44 ` [PATCH v3 8/8] KVM: arm64: Expose ID_AA64PFR2_EL1 to userspace and guests Marc Zyngier
2024-08-13 10:57 ` Joey Gouly
2024-08-13 12:47 ` Marc Zyngier [this message]
2024-08-13 13:38 ` Joey Gouly
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=86y150zj0r.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=broonie@kernel.org \
--cc=james.morse@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox