On Mon, Dec 05, 2022, David Matlack wrote: > On Mon, Dec 5, 2022 at 9:31 AM David Matlack <dmatlack@xxxxxxxxxx> wrote: > > > > On Mon, Dec 5, 2022 at 7:30 AM Peter Xu <peterx@xxxxxxxxxx> 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().
