Messages in this thread | | | From | Dan Williams <> | Date | Wed, 9 Jun 2021 14:38:26 -0700 | Subject | Re: [RFC v2-fix-v5 1/1] x86: Skip WBINVD instruction for VM guest |
| |
On Wed, Jun 9, 2021 at 2:03 PM Dave Hansen <dave.hansen@intel.com> wrote: > > This changelog lacks both clear problem statements and a clear solution > implemented within the patch. > > Here's a proposed changelog. It clearly spells out the two problems > caused by WBINVD within a guest, and the proposed solution which fixes > those two problems.
Looks good to me modulo the comment below...
> > Is this missing anything? > > -- > > VM guests that support ACPI use standard ACPI mechanisms to signal sleep > state entry to the host. To ACPI, reboot is simply another sleep state. > > ACPI specifies that the platform preserve memory contents over (some) > sleep states. It does not specify any requirements for data > preservation in CPU caches. The ACPI specification mandates the use of > WBINVD to flush the contents of the CPU caches to memory before entering > specific sleep states, thus ensuring data in caches can survive sleep > state transitions.e > > Unlike when entering sleep states bare metal, no actions within a guest > can cause data in processor caches to be lost. That makes these WBINVD > invocations harmless but superfluous within a guest. (<--- problem #1) > > In TDX guests, these WBINVD operations cause #VE exceptions. For debug, > it would be ideal for the #VE handler to be able to WARN() when an > unexpected WBINVD occurs. (<--- problem #2)
...but it doesn't WARN() it triggers unhandled #VE, unless I missed another patch that precedes this that turns it into a WARN()? If a code path expects WBINVD for correct operation and the guest can't execute that sounds fatal, not a WARN to me.
> Avoid WBINVD for all ACPI cache-flushing operations which occur while > running under a hypervisor, which includes TDX guests. This both avoids > TDX warnings and optimizes away superfluous WBINVD invocations. (<---- > solution) >
| |