On Wed, Mar 27, 2024 at 05:35:00PM +0000, Fuad Tabba wrote:

> Expand comment clarifying why the host value representing SVE
> vector length being restored for ZCR_EL1 on guest exit isn't the
> same as it was on guest entry.

> -			/* Restore the VL that was saved when bound to the CPU */
> +			/*
> +			 * Restore the VL that was saved when bound to the CPU,
> +			 * which is the maximum VL for the guest. Because
> +			 * the layout of the data when saving the sve state
> +			 * depends on the VL, we need to use a consistent VL.
> +			 * Note that this means that at guest exit ZCR_EL1 is
> +			 * not necessarily the same as on guest entry.

I don't know if a reference to the ZCR_EL1 fulfilling the role of
ZCR_EL2 when doing the save from EL2 in VHE mode, that's potentially a
bit more architecture to know but explains why we only need this for
nVHE.

> +			 * Flushing the cpu state sets the TIF_FOREIGN_FPSTATE
> +			 * bit for the context, which lets the kernel restore
> +			 * the sve state, including ZCR_EL1 later.
> +			 */

The bit about flushing probably wants to be commented on the flush
itself which is done unconditionally rather than only in the nVHE case,
put something in there about how we need to save and invalidate the
state so that if the host tries to use floating point it's not using
stale data from the guest.

>  			if (!has_vhe())
>  				sve_cond_update_zcr_vq(vcpu_sve_max_vq(vcpu) - 1,
>  						       SYS_ZCR_EL1);
> -- 
> 2.44.0.478.gd926399ef9-goog
>