Re: [RFC PATCH 00/12] dax: Add DAX to guest memfd support for KVM

[Ira Weiny <iweiny@fastmail.com>]

Ackerley Tng wrote:
> Dave Jiang <dave.jiang@intel.com> writes:
> 
> > On 4/24/26 10:13 AM, Frank van der Linden wrote:
> >> Dave Jiang <dave.jiang@intel.com> wrote:

[snip]

> 
> >>> [1]: https://lore.kernel.org/linux-cxl/aeWV1CvP9ImZ3eEG@gourry-fedora-PF4VCD3F/T/#t
> >>
> >> One of the main ideas behind guest_memfd is that the memory is managed
> >> by the kernel only, so it knows what it has and that it can trust
> >> the memory. This RFC passes an fd in via the ioctl(), which I think
> >> breaks that model.
> 
> Yup! One of guest_memfd's core purposes is to be able to block host
> accesses to guest private (in the CoCo sense) memory.
> 
> >
> > Don't we issue KVM_CREATE_GUEST_MEMFD ioctl to get a fd in userspace to be passed to KVM_SET_USER_MEMORY_REGION2 ioctl later? We are just passing in a DAX fd instead of a guest mem fd.
> >
> 
> This RFC is passing a DAX fd instead of a guest_memfd when creating a
> memslot, so it's not really using guest_memfd, it's just reusing the
> functions that were first created for guest_memfd to support another
> kind of fd.
> 
> What's the use case you're shooting for? Why not mmap() from the DAX
> fd and then pass the userspace address to KVM when setting up a memslot?
> 
> Is there a requirement to have the DAX memory usable by CoCo guests as
> well, and hence requiring guest_memfd-style protection from host
> accesses for private DAX memory?
> 

I was thinking this would be an eventual use case for DAX/CXL memory yes.

There are a couple of issues with mmaping DAX.

1) DAX is getting a bit long in the tooth.  It may be that users are fine
   with it and it should stick around but there are some who worry that it
   is too deviated from the memfd/gmemfd style of management.

2) What you propose above does not give the gmem 'protection' for CoCo's.
   So yea that is the bigger issue.

Allowing gmem to use DAX/CXL as a backend within the kernel is where I
think this is headed.  But having the gmem fd be allocated with that
backend would need to have more knobs in gmem.  Also I believe there may
be use cases where a _specific_ CXL device is desired.  That case makes
the knobs required more complicated.

What Dave has done here gives the device information via the dax fd.  It
is kind of clunky but it works...

Ira

[snip]