Re: [RFC v2-fix-v3 1/1] x86/tdx: Ignore WBINVD instruction for TDX guest

[Dan Williams <dan.j.williams@intel.com>]

On Wed, May 26, 2021 at 9:38 PM Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com> wrote:
>
> Functionally only devices outside the CPU (such as DMA devices,
> or persistent memory for flushing) can notice the external side
> effects from WBINVD's cache flushing for write back mappings. One
> exception here is MKTME, but that is not visible outside the TDX
> module and not possible inside a TDX guest.
>
> Currently TDX does not support DMA, because DMA typically needs
> uncached access for MMIO, and the current TDX module always sets
> the IgnorePAT bit, which prevents that.
>
> Persistent memory is also currently not supported. There are some
> other cases that use WBINVD, such as the legacy ACPI sleeps, but
> these are all not supported in virtualization and there are better
> mechanisms inside a guest anyways. The guests usually are not
> aware of power management. Another code path that uses WBINVD is
> the MTRR driver, but EPT/virtualization always disables MTRRs so
> those are not needed. This all implies WBINVD is not needed with
> current TDX.
>
> So handle the WBINVD instruction as nop. Currently, #VE exception
> handler does not include any warning for WBINVD handling because
> ACPI reboot code uses it. This is the same behavior as KVM. It
> only allows WBINVD in a guest when the guest supports VT-d (=DMA),
> but just handles it as a nop if it doesn't .
>
> If TDX ever gets DMA support, or persistent memory support, or
> some other devices that can observe flushing side effects, a
> hypercall can be added to implement it similar to AMD-SEV. But
> current TDX does not need it.

Please just drop this patch. It serves no purpose especially when the
assertion is that nothing in TDX will miss WBINVD. Why would Linux
merge a patch that has no claimed end user benefit? If the only known
usage of WBINVD in a TDX guest is the ACPI reboot path then add an
is_protected_guest() to that one usage.

If a TDX guest runs an unexpected WBINVD that's a bug that needs a kernel fix.