shinys000114/linux
1
0
Fork 0
mirror of https://github.com/hardkernel/linux.git synced 2026-06-06 02:50:49 +09:00
Code Issues Packages Projects Releases Wiki Activity

ANDROID: KVM: arm64: Clarify rationale for ZCR_EL1 value restored on guest exit

Browse Source 
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.

Signed-off-by: Fuad Tabba <tabba@google.com>

Bug: 267291591
Change-Id: I5889407b4391a80dfcf77b31375c3a17705b68da
This commit is contained in:
Fuad Tabba
2023-02-15 10:01:07 +00:00
committed by Lee Jones
parent d9e00246e0
commit ba446078c9
1 changed files with 12 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
arch/arm64/kvm/fpsimd.c
View File

@@ -178,7 +178,18 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
if (vcpu_has_sve(vcpu)) {
__vcpu_sys_reg(vcpu, ZCR_EL1) = read_sysreg_el1(SYS_ZCR);
/* 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.
*
* 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.
*/
if (!has_vhe())
sve_cond_update_zcr_vq(vcpu_sve_max_vq(vcpu) - 1,
SYS_ZCR_EL1);