Re: [PATCH v2] x86: Skip WBINVD instruction for VM guest

[Kirill A. Shutemov]

On Fri, Dec 03, 2021 at 04:20:34PM -0800, Dave Hansen wrote:
> On 12/3/21 3:49 PM, Kirill A. Shutemov wrote:
> > -	ACPI_FLUSH_CPU_CACHE();
> > +	if (acpi_state >= ACPI_STATE_S1 && acpi_state <= ACPI_STATE_S3)
> > +		ACPI_FLUSH_CPU_CACHE();
> 
> It's a bit of a bummer that this per-sleep-state logic has to be
> repeated so many time.
> 
> If you pass acpi_state into ACPI_FLUSH_CPU_CACHE() can you centralize
> the set of places where that knowledge about which sleep states require
> flushing?

Yes, sure, it is doable. It we decide that it is the way to go.

> > TDX doesn't support these S- and C-states. TDX is only supports S0 and S5.
> 
> This makes me a bit nervous.  Is this "the first TDX implementation
> supports..." or "the TDX architecture *prohibits* supporting S1 (or
> whatever"?

TDX Virtual Firmware Design Guide only states that "ACPI S3 (not supported
by TDX guests)".

Kernel reports in dmesg "ACPI: PM: (supports S0 S5)".

But I don't see how any state beyond S0 and S5 make sense in TDX context.
Do you?

I find it neat that adjusting ACPI code to conform the spec makes TDX
work.

> I really think we need some kind of architecture guarantee.  Without
> that, we risk breaking things if someone at our employer simply changes
> their mind.

Guarantees are hard.

If somebody change their mind we will get unexpected #VE and crash.
I think it is acceptable way to handle unexpected change in confidential
computing environment.

> The:
> 
> > #define ACPI_FLUSH_CPU_CACHE_PHYS()     \
> >         if (!cpu_feature_enabled(XXX))	\
> >         	wbinvd();               \  
> 
> does seem simpler and less error-prone than this, though.

If it it the way to go, I can make a patch.

But there's no reason to have ACPI_FLUSH_CPU_CACHE_PHYS in addition to
ACPI_FLUSH_CPU_CACHE. All ACPI_FLUSH_CPU_CACHE can skip cache flush on
TDX.

-- 
 Kirill A. Shutemov