On Thu, 2025-01-09 at 11:20 +0800, Binbin Wu wrote: > > > On 1/9/2025 10:46 AM, Huang, Kai wrote: > > On Thu, 2025-01-09 at 10:26 +0800, Binbin Wu wrote: > > > > > > I think we can just say TDX doesn't support vcpu reset no matter due to > > > > > > INIT event or not. > > > > That's not entirely accurate either though. TDX does support KVM's version of > > > > RESET, because KVM's RESET is "power-on", i.e. vCPU creation. Emulation of > > > > runtime RESET is userspace's responsibility. > > > > > > > > The real reason why KVM doesn't do anything during KVM's RESET is that what > > > > little setup KVM does/can do needs to be defered until after guest CPUID is > > > > configured. > > > > > > > > KVM should also WARN if a TDX vCPU gets INIT, no? > > > There was a KVM_BUG_ON() if a TDX vCPU gets INIT in v19, and later it was > > > removed during the cleanup about removing WARN_ON_ONCE() and KVM_BUG_ON(). > > > > > > Since INIT/SIPI are always blocked for TDX guests, a delivery of INIT > > > event is a KVM bug and a WARN_ON_ONCE() is appropriate for this case. > > Can TDX guest issue INIT via IPI? Perhaps KVM_BUG_ON() is safer? > TDX guests are not expected to issue INIT, but it could in theory. > It seems no serous impact if guest does it, not sure it needs to kill the > VM or not. > > Also, in this patch, for TDX kvm_apic_init_sipi_allowed() is always > returning false, so vt_vcpu_reset() will not be called with init=true. > Adding a WARN_ON_ONCE() is the guard for the KVM's logic itself, > not the guard for guest behavior. > Yeah agreed. I replied too early before looking at the patch.
