> On Apr 24, 2023, at 5:26 PM, Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Mon, Apr 24, 2023, Nadav Amit wrote: >> Feel free to tell me to shut up, as it is none of my business, and I might be >> missing a lot of context. Yet, it never stopped me before. :) >> >>> On Apr 24, 2023, at 1:35 PM, Sean Christopherson <seanjc@xxxxxxxxxx> wrote: >>> >>> On Mon, Apr 24, 2023, Nadav Amit wrote: >>>> >>>>> On Apr 24, 2023, at 10:54 AM, Anish Moorthy <amoorthy@xxxxxxxxxx> wrote: >>>>> 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. >>>> >>>> It certainly not my call. But if you ask me, introducing a solution for >>>> a concrete use-case that requires API changes/enhancements is not >>>> guaranteed to be the best solution. It may be better first to fully >>>> understand the existing overheads and agree that there is no alternative >>>> cleaner and more general solution with similar performance. >>> >>> KVM already returns -EFAULT for these situations, the change I really want to land >>> is to have KVM report detailed information about why the -EFAULT occurred. I'll be >>> happy to carry the code in KVM even if userspace never does anything beyond dumping >>> the extra information on failures. >> >> I thought that the change is to inform on page-faults through a new interface >> instead of the existing uffd-file-based one. There is already another interface >> (signals) and I thought (but did not upstream) io-uring. You now suggest yet >> another one. > > There are two capabilities proposed in this series: one to provide more information > when KVM encounters a fault it can't resolve, and another to tell KVM to kick out > to userspace instead of attempting to resolve a fault when a given address couldn't > be resolved with fast gup. I'm talking purely about the first one: providing more > information when KVM exits. > > As for the second, my plan is to try and stay out of the way and let people that > actually deal with the userspace side of things settle on an approach. From the > KVM side, supporting the "don't wait to resolve faults" flag is quite simple so > long as KVM punts the heavy lifting to userspace, e.g. identifying _why_ the address > isn't mapped with the appropriate permissions. Thanks for your kind and detailed reply. I removed the parts that I understand. As you might guess, I focus on the second part, which you leave for others. The interactions between two page-fault reporting mechanisms is not trivial, and it is already not fully correct. I understand the approach that Anish prefers is to do something that is tailored for KVM, but I am not sure it is the best thing.
