[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3ada3079-6f01-41d5-927f-afbbd57d934b@sirena.org.uk>
Date: Thu, 3 Jul 2025 19:03:12 +0100
From: Mark Brown <broonie@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Oliver Upton <oliver.upton@...ux.dev>, Joey Gouly <joey.gouly@....com>,
Catalin Marinas <catalin.marinas@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Will Deacon <will@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>,
Jonathan Corbet <corbet@....net>, Shuah Khan <shuah@...nel.org>,
Dave Martin <Dave.Martin@....com>, Fuad Tabba <tabba@...gle.com>,
Mark Rutland <mark.rutland@....com>,
linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
linux-doc@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v6 18/28] KVM: arm64: Support SME priority registers
On Sun, Jun 29, 2025 at 10:32:23AM +0100, Marc Zyngier wrote:
> Mark Brown <broonie@...nel.org> wrote:
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -495,6 +495,7 @@ enum vcpu_sysreg {
> > SVCR,
> > FPMR,
> > SMIDR_EL1, /* Streaming Mode Identification Register */
> > + SMPRI_EL1, /* Streaming Mode Priority Register */
> What is the point of making the sysreg file larger for the sole
> purpose of returning a value that is firmly always 0? Can't that be
> synthesised on the fly whenever needed?
This was patterned of what you'd done with SVCR, I'd formed the
impression that the idea was that for registers that really exist like
this one it was more robust and less code to set them up in the sysreg
file and have everything look standard than do custom handling. That
case was a bit different as the arch FP code needs a variable to point
at, I'll remove this and synthesise instead.
> > + EL2_REG_FILTERED(SMPRIMAP_EL2, trap_raz_wi, reset_val, 0,
> > + sme_el2_visibility),
> Wut??? You clearly said it yourself: this register "has no specific
> traps available". If you end-up here from a guest access, this is a
> bug. So this "trap_raz_wi" makes no sense.
I see, so the callback should be NULL? Access to the register will get
trapped as part of the general trapping of EL2 access by a NV hypervisor
so it wasn't clear to me that that we shouldn't have the handling.
> I also cannot see where this register is properly configured to be
> fully RES0, as it should.
Me either now that you point it out, thanks.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists