Re: [PATCH v2 16/20] vfio/cxl: Register regions with VFIO layer

[Jason Gunthorpe <jgg@ziepe.ca>]

On Mon, Apr 06, 2026 at 05:22:06PM -0400, Gregory Price wrote:
> On Sat, Apr 04, 2026 at 12:36:53PM -0700, Dan Williams wrote:
> > Jason Gunthorpe wrote:
> > > 
> > > The entire thing needs to be mmapable in a cache coherent way since
> > > that is what the HW semantic is. If you try to do something else you
> > > will break KVM support since it follows the VMA.
> > 
> > Then I assume it matters that memremap() sometimes silently falls back
> > to the direct map. The "VFIO owns" expectation needs to guard against
> > some helpful platform firmware mapping accelerator memory as System RAM.
> > 
> > At a minimum having VFIO fail to map in that case helps with the
> > argument I have been making that "no, EFI_CONVENTIONAL_MEMORY type +
> > EFI_SPECIFIC_PURPOSE flag" is not suitable for accelerators with private
> > CXL memory. Those want to be enforcing "EFI_RESERVED".
> 
> Agree - in fact I would argue any potential user of private nodes should
> have some kind of splat saying the memory should be marked reserved in
> the first place, otherwise it's a firmware bug.

I would expect this to happen via the request_resource mechanism, if
MM is using the CXL range it should be locked in the resource tree and
vfio should request it and then fail during the initial startup
phases.

> I need to read up a little bit on this area, but i don't see the "needs
> to be mmap'able in a cache coherent way" to be an argument for one
> particular method or another (hotplug, private node, memremap, etc).

It is speaking to what VFIO has to do. It is the exclusive owner of
the physical range, it does not have struct pages, it must be cachable
for VFIO and KVM to work - not alot of choices here. Turn the
phys_addr_t's into large cachable special PTEs inside a VMA.

Jason