On 3/28/2024 11:04 AM, Edgecombe, Rick P wrote:
On Thu, 2024-03-28 at 09:30 +0800, Xiaoyao Li wrote:
The current ABI of KVM_EXIT_X86_RDMSR when TDs are created is nothing. So I don't see how this
is
any kind of ABI break. If you agree we shouldn't try to support MTRRs, do you have a different
exit
reason or behavior in mind?
Just return error on TDVMCALL of RDMSR/WRMSR on TD's access of MTRR MSRs.
MTRR appears to be configured to be type "Fixed" in the TDX module. So the guest could expect to be
able to use it and be surprised by a #GP.
{
"MSB": "12",
"LSB": "12",
"Field Size": "1",
"Field Name": "MTRR",
"Configuration Details": null,
"Bit or Field Virtualization Type": "Fixed",
"Virtualization Details": "0x1"
},
If KVM does not support MTRRs in TDX, then it has to return the error somewhere or pretend to
support it (do nothing but not return an error). Returning an error to the guest would be making up
arch behavior, and to a lesser degree so would ignoring the WRMSR.
The root cause is that it's a bad design of TDX to make MTRR fixed1.
When guest reads MTRR CPUID as 1 while getting #VE on MTRR MSRs, it
already breaks the architectural behavior. (MAC faces the similar issue
, MCA is fixed1 as well while accessing MCA related MSRs gets #VE. This
is why TDX is going to fix them by introducing new feature and make them
configurable)
So that is why I lean towards
returning to userspace and giving the VMM the option to ignore it, return an error to the guest or
show an error to the user.
"show an error to the user" doesn't help at all. Because user cannot fix
it, nor does QEMU.
If KVM can't support the behavior, better to get an actual error in
userspace than a mysterious guest hang, right?
What behavior do you mean?
Outside of what kind of exit it is, do you object to the general plan to punt to userspace?
Since this is a TDX specific limitation, I guess there is KVM_EXIT_TDX_VMCALL as a general category
of TDVMCALLs that cannot be handled by KVM.
I just don't see any difference between handling it in KVM and handling
it in userspace: either a) return error to guest or b) ignore the WRMSR.
