> Check for additional CPUID bits to identify TDX guests running with Trust > Domain (TD) partitioning enabled. TD partitioning is like nested virtualization > inside the Trust Domain so there is a L1 TD VM(M) and there can be L2 TD VM(s). > > In this arrangement we are not guaranteed that the TDX_CPUID_LEAF_ID is > visible > to Linux running as an L2 TD VM. This is because a majority of TDX facilities > are controlled by the L1 VMM and the L2 TDX guest needs to use TD partitioning > aware mechanisms for what's left. So currently such guests do not have > X86_FEATURE_TDX_GUEST set. Back to this concrete patch. Why cannot L1 VMM emulate the correct value of the TDX_CPUID_LEAF_ID to L2 VM? It can do this per TDX partitioning arch. How do you handle this and other CPUID calls call currently in L1? Per spec, all CPUIDs calls from L2 will cause L2 --> L1 exit, so what do you do in L1? Given that you do that simple emulation, you already end up with TDX guest code being activated. Next you can check what features you wont be able to provide in L1 and create simple emulation calls for the TDG calls that must be supported and cannot return error. The biggest TDG call (TDVMCALL) is already direct call into L0 VMM, so this part doesn’t require L1 VMM support. Until we really see what breaks with this approach, I don’t think it is worth to take in the complexity to support different L1 hypervisors view on partitioning. Best Regards, Elena.
