diff options
author | Sean Christopherson <[email protected]> | 2021-05-04 10:17:25 -0700 |
---|---|---|
committer | Paolo Bonzini <[email protected]> | 2021-05-07 06:06:17 -0400 |
commit | 0caa0a77c2f6fcd0830cdcd018db1af98fe35e28 (patch) | |
tree | 50b3e9323465d985c8c8ba0de3dd90cd0403c037 /lib/mpi/mpi-sub-ui.c | |
parent | 5104d7ffcf24749939bea7fdb5378d186473f890 (diff) |
KVM: SVM: Probe and load MSR_TSC_AUX regardless of RDTSCP support in host
Probe MSR_TSC_AUX whether or not RDTSCP is supported in the host, and
if probing succeeds, load the guest's MSR_TSC_AUX into hardware prior to
VMRUN. Because SVM doesn't support interception of RDPID, RDPID cannot
be disallowed in the guest (without resorting to binary translation).
Leaving the host's MSR_TSC_AUX in hardware would leak the host's value to
the guest if RDTSCP is not supported.
Note, there is also a kernel bug that prevents leaking the host's value.
The host kernel initializes MSR_TSC_AUX if and only if RDTSCP is
supported, even though the vDSO usage consumes MSR_TSC_AUX via RDPID.
I.e. if RDTSCP is not supported, there is no host value to leak. But,
if/when the host kernel bug is fixed, KVM would start leaking MSR_TSC_AUX
in the case where hardware supports RDPID but RDTSCP is unavailable for
whatever reason.
Probing MSR_TSC_AUX will also allow consolidating the probe and define
logic in common x86, and will make it simpler to condition the existence
of MSR_TSX_AUX (from the guest's perspective) on RDTSCP *or* RDPID.
Cc: [email protected]
Signed-off-by: Sean Christopherson <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Diffstat (limited to 'lib/mpi/mpi-sub-ui.c')
0 files changed, 0 insertions, 0 deletions