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? 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?
