Re: [PATCH 5/9] x86/mtrr: use memory_type_changed() in hvm_set_mem_pinned_cacheattr()

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

On Fri, May 16, 2025 at 10:02:22AM +0200, Jan Beulich wrote:
> On 16.05.2025 09:48, Roger Pau Monné wrote:
> > Overall, I have the impression hvm_set_mem_pinned_cacheattr() should
> > only be used while building a domain, and hence the flush can likely
> > be skipped unconditionally, regardless of the type changes.
> 
> See my patch submission, which had this remark:
> 
> "Is it really sensible to add/remove ranges once the guest is already
>  running? (If it is, limiting the scope of the flush would be nice, but
>  would require knowing dirtyness for the domain wrt the caches, which
>  currently we don't track.)"

Well, I had an extra patch to attempt to do track vCPU dirtyness wrt
to the caches.

> 
> As apparently we both agree, why don't we reject requests post-creation
> then, and drop the flush? The one thing I'm uncertain about is whether
> the DM would actually have carried out the operation strictly ahead of
> the domain being first un-paused.

I've looked at QEMU, and I cannot convince myself the operation
couldn't be used against live domains, it's part of a memory listener
hook.

What is also concerning is that this seems to be completely ignored
when using AMD NPT, I can only find references to
hvm_get_mem_pinned_cacheattr() in EPT and shadow code.

Thanks, Roger.