On Tue, Aug 06, 2024, Oliver Upton wrote: > On Tue, Aug 06, 2024 at 11:14:15AM -0700, Anish Moorthy wrote: > > On Mon, Aug 5, 2024 at 3:51 PM Oliver Upton <oliver.upton@xxxxxxxxx> wrote: > > > > > > The wording of the cap documentation isn't as relaxed as I'd > > > anticipated. Perhaps: > > > > > > The presence of this capability indicates that KVM_RUN *may* fill > > > kvm_run.memory_fault if ... > > > > > > IOW, userspace is not guaranteed that the structure is filled for every > > > 'memory fault'. > > > > Agreed, I can add a patch to update the docs > > > > While we're at it, what do we think of removing this disclaimer? > > > > >Note: Userspaces which attempt to resolve memory faults so that they can retry > > > KVM_RUN are encouraged to guard against repeatedly receiving the same > > > error/annotated fault. > > > > I originally added this bit due to my concerns with the idea of > > filling kvm_run.memory_fault even for EFAULTs that weren't guaranteed > > to be returned by KVM_RUN [1]. > > This sort of language generally isn't necessary in UAPI descriptions. We > cannot exhaustively describe the ways userspace might misuse an > interface. I don't disagree in general, but I think this one is worth calling out because it's easy to screw up and arguably the most likely "failure" scenario. E.g. KVM has had multiple bugs (I can think of four off the top of my head) where a vCPU gets stuck because KVM doesn't resolve a fault. It's not hard to imagine userspace doing the same.
