On Thu, Oct 05, 2023, Anish Moorthy wrote:
> On Wed, Oct 4, 2023 at 6:14 PM Sean Christopherson <seanjc@xxxxxxxxxx> 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.
