[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220317230428.uqfbm6y7v2qbgknn@black.fi.intel.com>
Date: Fri, 18 Mar 2022 02:04:28 +0300
From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
luto@...nel.org, peterz@...radead.org,
sathyanarayanan.kuppuswamy@...ux.intel.com, aarcange@...hat.com,
ak@...ux.intel.com, dan.j.williams@...el.com, david@...hat.com,
hpa@...or.com, jgross@...e.com, jmattson@...gle.com,
joro@...tes.org, jpoimboe@...hat.com, knsathya@...nel.org,
pbonzini@...hat.com, sdeep@...are.com, seanjc@...gle.com,
tony.luck@...el.com, vkuznets@...hat.com, wanpengli@...cent.com,
thomas.lendacky@....com, brijesh.singh@....com, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCHv6 29/30] ACPICA: Avoid cache flush inside virtual machines
On Wed, Mar 16, 2022 at 03:13:18PM -0700, Dave Hansen wrote:
> On 3/15/22 19:08, Kirill A. Shutemov wrote:
> > While running inside virtual machine, the kernel can bypass cache
> > flushing. Changing sleep state in a virtual machine doesn't affect the
> > host system sleep state and cannot lead to data loss.
> >
> > Before entering sleep states, the ACPI code flushes caches to prevent
> > data loss using the WBINVD instruction. This mechanism is required on
> > bare metal.
> >
> > But, any use WBINVD inside of a guest is worthless. Changing sleep
> > state in a virtual machine doesn't affect the host system sleep state
> > and cannot lead to data loss, so most hypervisors simply ignore it.
> > Despite this, the ACPI code calls WBINVD unconditionally anyway.
> > It's useless, but also normally harmless.
> >
> > In TDX guests, though, WBINVD stops being harmless; it triggers a
> > virtualization exception (#VE). If the ACPI cache-flushing WBINVD
> > were left in place, TDX guests would need handling to recover from
> > the exception.
> >
> > Avoid using WBINVD whenever running under a hypervisor. This both
> > removes the useless WBINVDs and saves TDX from implementing WBINVD
> > handling.
>
> Looks good. Did you have more acks on this earlier that got removed? I
> thought I remembered more acks on earlier versions.
I missed Dan's Reviewed-by, but it was the only one that got to my inbox.
We had few (actually few too many) different approaches to address WBINVD
and some of them got acks. Dan was the only one who acked this version,
before current submission.
--
Kirill A. Shutemov
Powered by blists - more mailing lists