On 11/11/24 11:49, Tony Lindgren wrote: > On Thu, Oct 31, 2024 at 09:21:29PM +0200, Adrian Hunter wrote: >> On 30/10/24 21:00, Rick Edgecombe wrote: >>> Here is v2 of TDX VM/vCPU creation series. As discussed earlier, non-nits >>> from v1[0] have been applied and it’s ready to hand off to Paolo. A few >>> items remain that may be worth further discussion: >>> - Disable CET/PT in tdx_get_supported_xfam(), as these features haven’t >>> been been tested. >> >> It seems for Intel PT we have no support for restoring host >> state. IA32_RTIT_* MSR preservation is Init(XFAM(8)) which means >> the TDX Module sets the MSR to its RESET value after TD Enty/Exit. >> So it seems to me XFAM(8) does need to be disabled until that is >> supported. > > So for now, we should remove the PT bit from tdx_get_supported_xfam(), > but can still keep it in tdx_restore_host_xsave_state()? Yes > > Then for save/restore, maybe we can just use the pt_guest_enter() and > pt_guest_exit() also for TDX. Some additional checks are needed for > the pt_mode though as the TDX module always clears the state if PT is > enabled. And the PT_MODE_SYSTEM will be missing TDX enter/exit data > but might be otherwise usable. pt_guest_enter() / pt_guest_exit() are not suitable for TDX. pt_mode is not relevant for TDX because the TDX guest is always hidden from the host behind SEAM. However, restoring host MSRs is not the only issue. The TDX Module does not validate Intel PT CPUID leaf 0x14 (except it must be all zero if Intel PT is not supported i.e. if XFAM bit 8 is zero). For invalid MSR accesses by the guest, the TDX Module will inject #GP. Host VMM could provide valid CPUID to avoid that, but it would also need to be valid for the destination platform if migration was to be attempted. Disabling Intel PT for TDX for now also avoids that issue.
