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

[Jan Beulich <jbeulich@xxxxxxxx>]

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