On Mon, Jan 12, 2026 at 05:59:17PM +0000, Fuad Tabba wrote:
On Tue, 23 Dec 2025 at 01:22, Mark Brown broonie@kernel.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, 1ret+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.