On Thu, Feb 1, 2024 at 8:09 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Wed, Jan 31, 2024, Anish Moorthy wrote:
> > On Tue, Jan 30, 2024 at 4:26 PM James Houghton <jthoughton@xxxxxxxxxx> wrote:
> > >
> > > Feel free to add:
> > >
> > > Reviewed-by: James Houghton <jthoughton@xxxxxxxxxx>
> >
> > > If we include KVM_MEM_GUEST_MEMFD here, we should point the reader to
> > > KVM_SET_USER_MEMORY_REGION2 and explain that using
> > > KVM_SET_USER_MEMORY_REGION with this flag will always fail.
> >
> > Done and done (I've split the guest memfd doc update off into its own
> > commit too).
> >
> > > > @@ -3070,6 +3074,15 @@ kvm_pfn_t __gfn_to_pfn_memslot(const struct kvm_memory_slot *slot, gfn_t gfn,
> > > > writable = NULL;
> > > > }
> > > >
> > > > + if (!atomic && can_exit_on_missing
> > > > + && kvm_is_slot_exit_on_missing(slot)) {
>
> Operators go on the preceding line:
Thanks. On a side note, is this actually documented anywhere? I
searched coding-style.rst but couldn't find it.
> > > Perhaps we should have a comment for this? Maybe something like: "If
> > > we want to exit-on-missing, we want to bail out if fast GUP fails, and
> > > we do not want to go into slow GUP. Setting atomic=true does exactly
> > > this."
> >
> > I was going to push back on the use of "we" but I see that it's all
> > over kvm_main.c :).
>
> Ignore the ancient art, push back. The KVM code base is 15 years old at this
> point. A _lot_ of has changed in 15 years. The fact that KVM has existing code
> that's in violation of current standards doesn't justify ignoring the standards
> when adding new code.
Well, actually the idea to push back here was more mechanical- I'm a
fan of "we" in comments myself. Somehow I got the idea that it's
discouraged, but that might just be leakage from comments on my past
commit messages.
Again I don't see anything in coding-style.rst, but I wonder if I'm
missing something.
