On Fri, Aug 1, 2025 at 7:11 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Mon, Jul 28, 2025, James Houghton wrote:
> > On Wed, Jul 23, 2025 at 2:04 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> > > On Mon, Jul 07, 2025, James Houghton wrote:
> > > Right, but we also don't want to wait for the initial fault-in either, no? I.e.
> > > plumbing in MAP_POPULATE only fixes the worst of the delay, and maybe only with
> > > the TDP MMU enabled.
> > >
> > > In other words, it seems like we need a helper (option?) to excplitly "prefault",
> > > all memory from within the guest, not the ability to specify MAP_POPULATE.
> >
> > I don't want the EPT to be populated.
> >
> > In the event of a hugepage being executed, consider another memory
> > access. The access can either (1) be in the executed-from hugepage or
> > (2) be somewhere else.
> >
> > For (1), the optimization in this series doesn't help; we will often
> > be stuck behind the hugepage either being destroyed or reconstructed.
> >
> > For (2), the optimization in this series is an improvement, and that's
> > what this test is trying to demonstrate. But this is only true if the
> > EPT does not have a valid mapping for the GPA we tried to use. If it
> > does, the access will just proceed like normal.
> >
> > This test only times these "case 2" accesses. Now if we didn't have
> > MAP_POPULATE, then (non-fast) GUP time appears in these results, which
> > (IIRC) adds so much noise that the improvement is difficult to
> > ascertain. But with MAP_POPULATE, the difference is very clear.
>
> Oh, right, the whole point is to measure fault-in performance.
>
> In that case, rather than MAP_POPULATE, can we do the slightly more standard (for
> VMMs) thing of writing (or reading) memory from host userspace? I don't think it's
> worth plumbing in extra_mmap_flags just for MAP_POPULATE, in no small part because
> MAP_POPULATE is effectively best effort, and doesn't work for VM_PFNMAP (or VM_IO).
>
> Those quirks shouldn't matter for this case, and _probably_ won't ever matter for
> any KVM selftest, but it's enough to make me think MAP_POPULATE is a pattern we
> don't want to encourage.
What if vm_mem_add() just returned the VA of the added region, and
then the test could call mlock() on it? That's actually closer to what
I want; I want to avoid slow GUP as much as I can (though mlock()
isn't perfect, it's pretty much as good as we can do). So we can
write:
char *mem = vm_mem_add(...);
mlock(mem, size);
instead of
char *mem = vm_mem_add(...);
for (tmp = mem; tmp < mem + size; tmp += backing_src_pagesz)
*(volatile char *)tmp = 0;
