On Tue, Sep 17, 2024 at 07:37:21PM +0000, Jonathan Cameron wrote: > > * Said mechanism should not be explicitly CXL-specific. > > Somewhat agreed, but I don't want to invent a new spec just to avoid explicit > ties to CXL. I'm not against using CXL to present HBM / ACPI Specific Purpose > memory for example to a VM. It will trivially work if that is what a user > wants to do and also illustrates that this stuff doesn't necessarily just > apply to capacity on a memory pool - it might just be 'weird' memory on the host. > I suspect if you took all the DCD components of the current CXL device and repackaged it into a device called "DefinitelyNotACXLDCDDevice", that the CXL device inherited, this whole discussion goes away. Patches welcome? :] > > * Finding a tagged capacity devdax device in a VM should work the same as it > > does running on bare metal. > > Absolutely - that's a requirement. > > > * The file-backed (and devdax-backed) devdax abstraction is needed in qemu. > > Maybe. I'm not convinced the abstraction is needed at that particular level. > > > * Beyond that, I'm not yet sure what the lookup mechanism should be. Extra > > points for being easy to implement in both physical and virtual systems. > > For physical systems we aren't going to get agreement :( For the systems > I have visibility of there will be some diversity in hardware, but the > presentation to userspace and up consistency should be doable. > > Jonathan > > > > > Thanks for teeing this up! > > John > > > > > > [1] https://github.com/cxl-micron-reskit/famfs/blob/master/README.md > > > >
