On Mon, Jan 12, 2026 at 05:59:17PM +0000, Fuad Tabba wrote:

On Tue, 23 Dec 2025 at 01:22, Mark Brown [off-list ref] wrote:

quoted

+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.

quoted

+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

quoted

+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.