Re: [PATCH v2 2/6] x86/HVM: restrict guest-induced WBINVD to cache writeback

["Roger Pau Monné" <roger.pau@citrix.com>]

On Tue, May 13, 2025 at 03:54:56PM +0200, Jan Beulich wrote:
> On 13.05.2025 15:41, Roger Pau Monné wrote:
> > On Wed, May 03, 2023 at 11:45:22AM +0200, Jan Beulich wrote:
> >> We allow its use for writeback purposes only anyway, so let's also carry
> >> these out that way on capable hardware.
> > 
> > "for writeback purposes only" > is such the case because we cannot
> > guarantee the guest in which state the cache will be when resuming
> > from a wbinvd operation, and hence won't be "clean"?
> 
> Not really, no (see below). This is inferred from us limiting flushing
> operations to domains with physical hardware assigned plus the fact
> that we avoid the overhead in vmx_do_resume() when the IOMMU is snoop-
> capable. (Plus I did all this work over 2 years ago, and hence I now
> don't recall what other commentary I may have come across saying
> things along these lines.)
> 
> Which, thinking about it while writing this reply (and also taking
> into consideration Andrew's earlier reply), may be all wrong.

As part of my series I was introducing a new option to allow guests
cache control even when no devices are assigned.  My intention was
that whether a guest needs cache control or not is known at creation
time and stays immutable, and to also allow easier testing of the
cache control code without a physical device assigned.

> > It's my understanding that the same is possible on native, as the CPU
> > might speculatively pull lines into the cache.  So there's no reason
> > for an OS to use wbinvd if wbnoinvd is available?
> 
> Speculatively pulling data into the cache is possible only when page
> table entries permit caching. Hence after changing all mappings of a
> certain page to UC, an OS may have a need to ensure that no data of
> this page is left in any cache (and it can't be pulled back in
> speculatively then).

Is this realistic taking into account the OS is running virtualized?

At least with Xen there's the direct map, so once context is switched
back to Xen (for example to execute the wbinvd itself) there's no
guarantee the CPU won't speculatively populate the cache with entries
from the direct map.

Thanks, Roger.