lkml.org 
[lkml]   [2021]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC v2-fix-v2 2/2] x86/tdx: Ignore WBINVD instruction for TDX guest
From
Date

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.

\
 
 \ /
  Last update: 2021-05-25 05:28    [W:0.158 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site