On 1/27/2021 2:01 AM, Paolo Bonzini wrote:
On 07/08/20 10:48, Chenyi Qiang wrote:+{ + struct vcpu_vmx *vmx = to_vmx(vcpu); + unsigned long *msr_bitmap = vmx->vmcs01.msr_bitmap; + bool pks_supported = guest_cpuid_has(vcpu, X86_FEATURE_PKS); + + /* + * set intercept for PKRS when the guest doesn't support pks + */+ vmx_set_intercept_for_msr(msr_bitmap, MSR_IA32_PKRS, MSR_TYPE_RW, !pks_supported);+ + if (pks_supported) { + vm_entry_controls_setbit(vmx, VM_ENTRY_LOAD_IA32_PKRS); + vm_exit_controls_setbit(vmx, VM_EXIT_LOAD_IA32_PKRS); + } else { + vm_entry_controls_clearbit(vmx, VM_ENTRY_LOAD_IA32_PKRS); + vm_exit_controls_clearbit(vmx, VM_EXIT_LOAD_IA32_PKRS); + }Is the guest expected to do a lot of reads/writes to the MSR (e.g. at every context switch)?
In current design for PKS, the PMEM stray write protection is the only implemented use case, and PKRS is only temporarily changed during specific code paths. Thus reads/writes to MSR is not so frequent, I think.
Even if this is the case, the MSR intercepts and the entry/exit controls should only be done if CR4.PKS=1. If the guest does not use PKS, KVM should behave as if these patches did not exist.
I pass through the PKRS and enable the entry/exit controls when PKS is supported, and just want to narrow down the window of MSR switch during the VMX transition. But yeah, I should also consider the enabling status of guest PKS according to CR4.PKS, will fix it in next version.
Paolo
