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
