Messages in this thread | | | Subject | Re: [RFC v2-fix-v2 2/2] x86/tdx: Ignore WBINVD instruction for TDX guest | From | Andi Kleen <> | Date | Mon, 24 May 2021 20:27:05 -0700 |
| |
On 5/24/2021 7:49 PM, Dan Williams wrote: > On Mon, May 24, 2021 at 7:13 PM Andi Kleen <ak@linux.intel.com> wrote: > [..] >>> ...to explicitly error out a wbinvd use case before data is altered >>> and wbinvd is needed. >> I don't see any point of all of this. We really just want to be the same >> as KVM. Not get into the business of patching a bazillion sub systems >> that cannot be used in TDX anyways. > Please let's not start this patch off with dubious claims of safety > afforded by IgnorePAT. Instead make the true argument that wbinvd is > known to be problematic in guests
That's just another reason to not support WBINVD, but I don't think it's the main reason. The main reason is that it is simply not needed, unless you do DMA in some form.
(and yes I consider direct mapping of persistent memory with a complex setup procedure a form of DMA -- my guess is that the reason that it works in KVM is that it somehow activates the DMA code paths in KVM)
IMNSHO that's the true reason.
> and for that reason many bare metal > use cases that require wbinvd have not been ported to guests (like > PMEM unlock), and others that only use wbinvd to opportunistically > enforce a cache state (like ACPI sleep states)
ACPI sleep states are not supported or needed in virtualization. They are mostly obsolete on real hardware too.
> do not see ill effects > from missing wbinvd. Given KVM ships with a policy to elide wbinvd in > many scenarios adopt the same policy for TDX guests.
| |