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
