On 6/1/22 04:46, Like Xu wrote:
On 1/6/2022 2:37 am, Sean Christopherson wrote:
On Tue, May 31, 2022, Paolo Bonzini wrote:
Whenever an MSR is part of KVM_GET_MSR_INDEX_LIST, as is the case for
MSR_IA32_DS_AREA, MSR_ARCH_LBR_DEPTH or MSR_ARCH_LBR_CTL, it has to be
always settable with KVM_SET_MSR. Accept a zero value for these MSRs
to obey the contract.
Do we have a rule to decide whether to put MSRs into
KVM_GET_MSR_INDEX_LIST,
for example a large number of LBR MSRs do not appear in it ?
In general I think it's much better to include them. The only reason
not to include them should be if the number of MSRs is variable and the
actual number is accessible via KVM_GET_SUPPORTED_CPUID, a feature MSR,
or KVM_CHECK_EXTENSION.
This is wrong, it will allow an unchecked wrmsrl() to
MSR_ARCH_LBR_DEPTH if
X86_FEATURE_ARCH_LBR is not supported by hardware but userspace forces
it in
guest CPUID.
What should we expect if the userspace forces guest to use features not
supported by KVM,
especially the emulation of this feature depends on the functionality of
host and guest vcpu model ?
Certainly not a WARN or invalid vmwrite.
Paolo
