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.
