On Tue, 2024-08-06 at 07:03 -0700, Sean Christopherson wrote: > On Tue, Aug 06, 2024, David Woodhouse wrote: > > On Mon, 2024-08-05 at 17:45 -0700, Sean Christopherson wrote: > > > On Mon, Aug 05, 2024, David Woodhouse wrote: > > > > From: David Woodhouse <dwmw@xxxxxxxxxxxx> > > > Servicing guest pages faults has the same problem, which is why > > > mmu_invalidate_retry_gfn() was added. Supporting hva-only GPCs made our lives a > > > little harder, but not horrifically so (there are ordering differences regardless). > > > > > > Woefully incomplete, but I think this is the gist of what you want: > > > > Hm, maybe. It does mean that migration occurring all through memory > > (indeed, just one at top and bottom of guest memory space) would > > perturb GPCs which remain present. > > If that happens with a real world VMM, and it's not a blatant VMM goof, then we > can fix KVM. The stage-2 page fault path hammers the mmu_notifier retry logic > far more than GPCs, so if a range-based check is inadequate for some use case, > then we definitely need to fix both. FWIW this turned out to be because someone used C++ where they shouldn't have done. Opinion is divided on whether to call that a 'blatant VMM goof'. But if you use std::vector for something that's modified that many times a second, and free() implicitly calls madvise(MADV_DONTNEED) every time, you get what you deserve :) We should still fix it in the kernel.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
