On 2024-03-08 01:20 PM, Huang, Kai wrote:
> > > > +:Parameters: struct kvm_memory_mapping(in/out)
> > > > +:Returns: 0 on success, <0 on error
> > > > +
> > > > +KVM_MAP_MEMORY populates guest memory without running vcpu.
> > > > +
> > > > +::
> > > > +
> > > > + struct kvm_memory_mapping {
> > > > + __u64 base_gfn;
> > > > + __u64 nr_pages;
> > > > + __u64 flags;
> > > > + __u64 source;
> > > > + };
> > > > +
> > > > + /* For kvm_memory_mapping:: flags */
> > > > + #define KVM_MEMORY_MAPPING_FLAG_WRITE _BITULL(0)
> > > > + #define KVM_MEMORY_MAPPING_FLAG_EXEC _BITULL(1)
> > > > + #define KVM_MEMORY_MAPPING_FLAG_USER _BITULL(2)
> > >
> > > I am not sure what's the good of having "FLAG_USER"?
> > >
> > > This ioctl is called from userspace, thus I think we can just treat this always
> > > as user-fault?
> >
> > The point is how to emulate kvm page fault as if vcpu caused the kvm page
> > fault. Not we call the ioctl as user context.
>
> Sorry I don't quite follow. What's wrong if KVM just append the #PF USER
> error bit before it calls into the fault handler?
>
> My question is, since this is ABI, you have to tell how userspace is
> supposed to use this. Maybe I am missing something, but I don't see how
> USER should be used here.
If we restrict this API to the TDP MMU then KVM_MEMORY_MAPPING_FLAG_USER
is meaningless, PFERR_USER_MASK is only relevant for shadow paging.
KVM_MEMORY_MAPPING_FLAG_WRITE seems useful to allow memslots to be
populated with writes (which avoids just faulting in the zero-page for
anon or tmpfs backed memslots), while also allowing populating read-only
memslots.
I don't really see a use-case for KVM_MEMORY_MAPPING_FLAG_EXEC.
