On Tue, Nov 12, 2024 at 09:26:36AM +0200, Adrian Hunter wrote: > 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. OK thanks for the detailed explanation. Regards, Tony
