On Mon, 2021-10-25 at 14:22 +0200, Paolo Bonzini wrote: > On 25/10/21 14:19, David Woodhouse wrote: > > So, with a fixed version of kvm_map_gfn() I suppose I could do the > > same, but that's *two* maps/unmaps for each interrupt? That's probably > > worse than just bouncing out and letting userspace do it! > > Absolutely! The fixed version of kvm_map_gfn should not do any > map/unmap, it should do it eagerly on MMU notifier operations. Staring at this some more... what *currently* protects a gfn_to_pfn_cache when the page tables change — either because userspace either mmaps something else over the same HVA, or the underlying page is just swapped out and restored? I don't see that our MMU notifiers will do anything to invalidate e.g. kvm->arch.st.cache, and thus record_steal_time() will just keep kmapping and writing to the *original* underlying cached pfn, long after that page no longer even belongs to the process running KVM? I think I'd prefer to fix that instead of making excuses for it and leaving it around as an example, but... I think that *if* it's a standard page (not IOMEM) then we do hold a reference on the page so it won't be *freed* and used by any other process, and I think that even means it won't be swapped out? So the only interesting failure modes are if the VMM explicitly mmaps something else over the referenced page (don't do that then?) or if the VMM is managing IOMEM pages explicitly and swaps out the page the guest is using for steal time reporting?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
