On 11/5/2024 5:59 PM, Paolo Bonzini wrote:
On 11/5/24 07:24, Xiaoyao Li wrote:
Signed-off-by: Xiaoyao Li <xiaoyao.li@xxxxxxxxx>
---
target/i386/kvm/tdx.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/target/i386/kvm/tdx.c b/target/i386/kvm/tdx.c
index 9cb099e160e4..05475edf72bd 100644
--- a/target/i386/kvm/tdx.c
+++ b/target/i386/kvm/tdx.c
@@ -734,6 +734,13 @@ static int
tdx_check_features(X86ConfidentialGuest *cg, CPUState *cs)
requested = env->features[w];
unavailable = requested & ~actual;
+ /*
+ * Intel enumerates SYSCALL bit as 1 only when processor in
64-bit
+ * mode and before vcpu running it's not in 64-bit mode.
+ */
+ if (w == FEAT_8000_0001_EDX && unavailable &
CPUID_EXT2_SYSCALL) {
+ unavailable &= ~CPUID_EXT2_SYSCALL;
+ }
mark_unavailable_features(cpu, w, unavailable, unav_prefix);
if (unavailable) {
mismatch = true;
This seems like a TDX module bug?
I don't think so. The value of CPUID_EXT2_SYSCALL depends on the mode of
the vcpu. Per SDM, it's 0 outside 64-bit mode.
The initial state of TDX vcpu is 32-bit protected mode. At the time of
calling KVM_TDX_GET_CPUID, vcpu hasn't started running. So the value
should be 0.
There indeed is a TDX module. After vcpu starts running and TD guest
switches to 64-bit mode. The value of this bit returned by TDX module
via global metadata CPUID value still remains 0.
Off the topic, for me, it's really a bad API to return TDX's CPUID value
via TD-scope metadata. It fits better with TD VCPU scope metadata.
It's the kind of thing that I guess
could be worked around in KVM.
If we do it in QEMU, I'd rather see it as
actual = cpuid_entry_get_reg(entry, wi->cpuid.reg);
switch (w) {
case FEAT_8000_0001_EDX:
actual |= CPUID_EXT2_SYSCALL;
break;
}
break;
I'll change to this way.
Paolo
