diff options
author | Sean Christopherson <[email protected]> | 2023-06-06 17:43:09 -0700 |
---|---|---|
committer | Sean Christopherson <[email protected]> | 2023-08-02 16:37:26 -0700 |
commit | a2fd5d02bad6d63daaaf4a8bb19c2400387aca61 (patch) | |
tree | e195af2bb5b47e59033b9c6d07270481fb08f49a /net/lapb/lapb_out.c | |
parent | af8e2ccfa6f101f505add076c1a4d56c718e0d50 (diff) |
KVM: x86: Snapshot host's MSR_IA32_ARCH_CAPABILITIES
Snapshot the host's MSR_IA32_ARCH_CAPABILITIES, if it's supported, instead
of reading the MSR every time KVM wants to query the host state, e.g. when
initializing the default value during vCPU creation. The paths that query
ARCH_CAPABILITIES aren't particularly performance sensitive, but creating
vCPUs is a frequent enough operation that burning 8 bytes is a good
trade-off.
Alternatively, KVM could add a field in kvm_caps and thus skip the
on-demand calculations entirely, but a pure snapshot isn't possible due to
the way KVM handles the l1tf_vmx_mitigation module param. And unlike the
other "supported" fields in kvm_caps, KVM doesn't enforce the "supported"
value, i.e. KVM treats ARCH_CAPABILITIES like a CPUID leaf and lets
userspace advertise whatever it wants. Those problems are solvable, but
it's not clear there is real benefit versus snapshotting the host value,
and grabbing the host value will allow additional cleanup of KVM's
FB_CLEAR_CTRL code.
Link: https://lore.kernel.org/all/[email protected]
Cc: Chao Gao <[email protected]>
Cc: Xiaoyao Li <[email protected]>
Reviewed-by: Chao Gao <[email protected]>
Reviewed-by: Xiaoyao Li <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sean Christopherson <[email protected]>
Diffstat (limited to 'net/lapb/lapb_out.c')
0 files changed, 0 insertions, 0 deletions