linux-kernel - Re: [PATCH v9 19/30] KVM: arm64: Provide assembly for SME register access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6f0e94ab-7c9c-4705-a90b-aea09ca629de@sirena.org.uk>
Date: Tue, 13 Jan 2026 19:20:22 +0000
From: Mark Brown <broonie@...nel.org>
To: Fuad Tabba <tabba@...gle.com>
Cc: Marc Zyngier <maz@...nel.org>, 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>,
	Oliver Upton <oupton@...nel.org>, Dave Martin <Dave.Martin@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ben Horgan <ben.horgan@....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,
	Peter Maydell <peter.maydell@...aro.org>,
	Eric Auger <eric.auger@...hat.com>
Subject: Re: [PATCH v9 19/30] KVM: arm64: Provide assembly for SME register
 access

On Mon, Jan 12, 2026 at 05:59:17PM +0000, Fuad Tabba wrote:
> On Tue, 23 Dec 2025 at 01:22, Mark Brown <broonie@...nel.org> wrote:

> > +void __sme_save_state(void const *state, bool restore_zt);
> > +void __sme_restore_state(void const *state, bool restore_zt);

> Would it be a good idea to pass the VL to these functions. Currently,
> they assume that the hardware's current VL matches the buffer's
> intended layout. But if there is a mismatch between the guest's VL and
> the current one, this could be difficult to debug. Passing the VL and
> checking it against _sme_rdsvl would be an inexpensive way to avoid
> these.

This mirrors the way that we've handled this for the SVE and for the
host kernel.  We don't really have any good way to tell anything about
problems if things go wrong inside the hypervisor.

> > +SYM_FUNC_START(__sve_get_vl)
> > +       _sve_rdvl       0, 1
> > +       ret
> > +SYM_FUNC_END(__sve_get_vl)

> Since this is just one instruction, would it be better to implement it
> as an inline assembly in the header file rather than a full
> SYM_FUNC_START, to reduce the overhead?

Actually this isn't referenced anymore so could just be deleted.  It
mirrors what we've got in the host code, we have to hand assemble
everything because we still don't require binutils that supports SVE,
let alone SME, and that's done with macros that do argument validation
which don't play nice with C.  Even with an assembler that supports the
instruction using a SVE instruction from C code gets annoying.  It has
crossed my mind to inline but it never seemed worth the effort

> > +SYM_FUNC_START(__sme_save_state)

> I think that this needs an isb(). We need to ensure that SMCR updates
> are visible here. Looking ahead to where you introduce
> __hyp_sme_save_guest(), that doesn't have a barrier after updating
> SMCR. The alternative is to call the barrier where it's needed, but
> make sure that this is well documented.

I think we should put the barrier where the update that needs it is.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)