Re: [PATCH v5 04/17] KVM: Add KVM_CAP_MEMORY_FAULT_INFO

[Sean Christopherson <seanjc@google.com>]

On Thu, Oct 05, 2023, Anish Moorthy wrote:
> On Wed, Oct 4, 2023 at 6:14 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > And peeking at future patches, pass in the RWX flags as bools, that way this
> > helper can deal with the bools=>flags conversion.  Oh, and fill the flags with
> > bitwise ORs, that way future conflicts with private memory will be trivial to
> > resolve.
> >
> > E.g.
> >
> > static inline void kvm_prepare_memory_fault_exit(struct kvm_vcpu *vcpu,
> >                                                  gpa_t gpa, gpa_t size,
> >                                                  bool is_write, bool is_exec)
> > {
> >         vcpu->run->exit_reason = KVM_EXIT_MEMORY_FAULT;
> >         vcpu->run->memory_fault.gpa = gpa;
> >         vcpu->run->memory_fault.size = size;
> >
> >         vcpu->run->memory_fault.flags = 0;
> >         if (is_write)
> >                 vcpu->run->memory_fault.flags |= KVM_MEMORY_FAULT_FLAG_WRITE;
> >         else if (is_exec)
> >                 vcpu->run->memory_fault.flags |= KVM_MEMORY_FAULT_FLAG_EXEC;
> >         else
> >                 vcpu->run->memory_fault.flags |= KVM_MEMORY_FAULT_FLAG_READ;
> > }
> 
> Is a BUG/VM_BUG_ON() warranted in the (is_write && is_exec) case do
> you think?

Nah, not here.  If we really wanted to add a sanity check, a KVM_MMU_WARN_ON()
in kvm_mmu_page_fault() would be the way to go.

> I see that user_mem_abort already VM_BUG_ON()s for this case, but if there's
> one in the x86 page fault path I don't immediately see it. Also this helper
> could be called from other paths, so maybe there's some value in it.
> 
> > I'll send you a clean-ish patch to use as a starting point sometime next week.
> 
> You mean something containing the next spin of the guest memfd stuff?
> Or parts of David's series as well?

guest_memfd stuff.  Effectively this patch, just massaged to splice together all
of the fixups.