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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

> 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).

IOW if the goal of the OS is write-back, then indeed it should prefer
WBNOINVD if available. Yet the same "replacement" isn't possible when
the goal is pruning of the cache(s).

Jan