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. > Considering the mess that KVM async-PF introduced, I would be very careful > before introducing such API changes. I did not look too much on the details, > but some things anyhow look slightly strange (which might be since I am > out-of-touch with KVM). For instance, returning -EFAULT on from KVM_RUN? I > would have assumed -EAGAIN would be more appropriate since the invocation did > succeed. Yeah, returning -EFAULT is somewhat odd, but as above, that's pre-existing behavior that's been around for many years.
