On Thu, Feb 01, 2024, Oliver Upton wrote: > On Wed, Jan 31, 2024 at 04:26:08PM -0800, James Houghton wrote: > > On Wed, Jan 31, 2024 at 2:00 PM Anish Moorthy <amoorthy@xxxxxxxxxx> wrote: > > [...] > > > On that note, I think we need to drop the patch that causes > > read-faults in RO memslots to go through fast GUP. KVM didn't do that > > for a good reason[1]. > > > > That would break KVM_EXIT_ON_MISSING for RO memslots, so I think that > > the right way to implement KVM_EXIT_ON_MISSING is to have > > hva_to_pfn_slow pass FOLL_NOFAULT, at least for the RO memslot case. > > We still get the win we're looking for: don't grab the userfaultfd > > locks. > > Is there even a legitimate use case that warrants optimizing faults on > RO memslots? My expectation is that the VMM uses these to back things > like guest ROM, or at least that's what QEMU does. In that case I'd > expect faults to be exceedingly rare, and if the VMM actually cared it > could just pre-populate the primary mapping. > > I understand why we would want to support KVM_EXIT_ON_MISSING for the > sake of completeness of the UAPI, but it'd be surprising if this > mattered in the context of post-copy. Yeah, I let's just make KVM_EXIT_ON_MISSING mutually exclusive with KVM_MEM_READONLY. KVM (oviously) honors the primary MMU protections, so userspace can (and does) map read-only memory into the guest without READONLY. As Oliver pointed out, making the *memslot* RO is intended for use cases where userspace wants writes to be treated like emulated MMIO. We can always add support in the future in the extremely unlikely event someone comes along with a legitimate reason for KVM_EXIT_ON_MISSING to play nice with KVM_MEM_READONLY.
