On 14.05.2025 16:42, Roger Pau Monné wrote: > On Wed, May 14, 2025 at 02:46:32PM +0200, Jan Beulich wrote: >> On 14.05.2025 13:30, Roger Pau Monné wrote: >>> On Tue, May 13, 2025 at 03:54:56PM +0200, Jan Beulich wrote: >>>> On 13.05.2025 15:41, Roger Pau Monné wrote: >>>>> 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. >> >> Well, we've been knowing for a long time that we're not doing things fully >> correctly there. Once a guest has changed all mappings of a page it owns, >> we ought to make the direct map one follow suit (or simply unmap it from >> there). > > Keeping track of guests mappings seems extremely complicated - maybe > doable for PV, but not for HVM with HAP I would think?
Indeed. > Also we would need to do something similar if guest enables CR0.CD and > switch all the direct map entries to uncached? Likely, yes. > Address Space Isolation (and the removal of the direct map) might > solve part of this, but still I don't think we can fully guarantee Xen > won't have any mapping of guest pages with a different set of cache > attributes. Yet for correctness we ought to, I fear. Jan
