Re: [PATCH v2 2/5] KVM: arm64: Get rid of host SVE tracking/saving

[Zenghui Yu <yuzenghui@huawei.com>]

Hi Marc,

On 2021/10/28 19:16, Marc Zyngier wrote:
> The SVE host tracking in KVM is pretty involved. It relies on a
> set of flags tracking the ownership of the SVE register, as well
> as that of the EL0 access.
> 
> It is also pretty scary: __hyp_sve_save_host() computes
> a thread_struct pointer and obtains a sve_state which gets directly
> accessed without further ado, even on nVHE. How can this even work?
> 
> The answer to that is that it doesn't, and that this is mostly dead
> code. Closer examination shows that on executing a syscall, userspace
> loses its SVE state entirely. This is part of the ABI. Another
> thing to notice is that although the kernel provides helpers such as
> kernel_neon_begin()/end(), they only deal with the FP/NEON state,
> and not SVE.
> 
> Given that you can only execute a guest as the result of a syscall,
> and that the kernel cannot use SVE by itself, it becomes pretty
> obvious that there is never any host SVE state to save, and that
> this code is only there to increase confusion.
> 
> Get rid of the TIF_SVE tracking and host save infrastructure altogether.
> 
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index 5621020b28de..38ca332c10fe 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -73,15 +73,11 @@ int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu)
>  void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
>  {
>  	BUG_ON(!current->mm);
> +	BUG_ON(test_thread_flag(TIF_SVE));
>  
> -	vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED |
> -			      KVM_ARM64_HOST_SVE_IN_USE |
> -			      KVM_ARM64_HOST_SVE_ENABLED);
> +	vcpu->arch.flags &= ~KVM_ARM64_FP_ENABLED;
>  	vcpu->arch.flags |= KVM_ARM64_FP_HOST;
>  
> -	if (test_thread_flag(TIF_SVE))
> -		vcpu->arch.flags |= KVM_ARM64_HOST_SVE_IN_USE;

The comment about TIF_SVE on top of kvm_arch_vcpu_load_fp() becomes
obsolete now. Maybe worth removing it?

| *
| * TIF_SVE is backed up here, since it may get clobbered with guest state.
| * This flag is restored by kvm_arch_vcpu_put_fp(vcpu).

> diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> index a0e78a6027be..722dfde7f1aa 100644
> --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> @@ -207,16 +207,6 @@ static inline bool __populate_fault_info(struct kvm_vcpu *vcpu)
>  	return __get_fault_info(esr, &vcpu->arch.fault);
>  }
>  
> -static inline void __hyp_sve_save_host(struct kvm_vcpu *vcpu)
> -{
> -	struct thread_struct *thread;
> -
> -	thread = container_of(vcpu->arch.host_fpsimd_state, struct thread_struct,
> -			      uw.fpsimd_state);
> -
> -	__sve_save_state(sve_pffr(thread), &vcpu->arch.host_fpsimd_state->fpsr);
> -}

Nit: This removes the only user of __sve_save_state() helper. Should we
still keep it in fpsimd.S?

Thanks,
Zenghui