On Fri, Apr 21, 2023 at 10:40 AM Nadav Amit <nadav.amit@xxxxxxxxx> wrote: > > If I understand the problem correctly, it sounds as if the proper solution > should be some kind of a range-locks. If it is too heavy or the interface can > be changed/extended to wake a single address (instead of a range), > simpler hashed-locks can be used. Some sort of range-based locking system does seem relevant, although I don't see how that would necessarily speed up the delivery of faults to UFFD readers: I'll have to think about it more. On the KVM side though, I think there's value in merging KVM_CAP_ABSENT_MAPPING_FAULT and allowing performance improvements to UFFD itself proceed separately. It's likely that returning faults directly via the vCPU threads will be faster than even an improved UFFD, since the former approach basically removes one level of indirection. That seems important, given the criticality of the EPT-violation path during postcopy. Furthermore, if future performance improvements to UFFD involve changes/restrictions to its API, then KVM_CAP_ABSENT_MAPPING_FAULT could well be useful anyways. Sean did mention that he wanted KVM_CAP_MEMORY_FAULT_INFO in general, so I'm guessing (some version of) that will (eventually :) be merged in any case.
