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 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). If this extension starts bleeding into special-casing a bunch more mm/ stuff to be aware of and handle special memremap'd memory, that's when I would argue maybe we need to take a look at whether nodes apply. But if this just wants to pass a whole chunk from driver to guest and otherwise the host is supposed to stay out of the way - memremap seems like an ok start / a reasonable existing upstream solution. ~Gregory
