Re: [RFC] Improving userfaultfd scalability for live migration

[Sean Christopherson <seanjc@google.com>]

On Mon, Dec 05, 2022, David Matlack wrote:
> On Mon, Dec 5, 2022 at 9:31 AM David Matlack <dmatlack@google.com> wrote:
> >
> > On Mon, Dec 5, 2022 at 7:30 AM Peter Xu <peterx@redhat.com> wrote:
> > >
> > > On Sat, Dec 03, 2022 at 01:03:38AM +0000, Sean Christopherson wrote:
> > > > On Thu, Dec 01, 2022, James Houghton wrote:
> > > > > == Problems ==
> > > > > The major problem here is that this only solves the scalability
> > > > > problem for the KVM demand paging case. Other userfaultfd users, if
> > > > > they have scalability problems, will need to find another approach.
> > > >
> > > > It may not fully solve KVM's problem either.  E.g. if the VM is running nested
> > > > VMs, many (most?) of the user faults could be triggered by FNAME(walk_addr_generic)
> > > > via __get_user() when walking L1's EPT tables.
> >
> > We could always modify FNAME(walk_addr_generic) to return out to user
> > space in the same way if that is indeed another bottleneck.
> 
> Scratch that, walk_addr_generic ultimately has a ton of callers
> throughout KVM, so it would be difficult to plumb the error handling
> out to userspace.

It would be easy enough to plumb a "fast-only" flag into walk_addr_generic().