On 21-01-27 22:33:37, Igor Mammedov wrote: > On Wed, 27 Jan 2021 12:25:44 -0800 > Ben Widawsky <b...@bwidawsk.net> wrote: > > > On 21-01-27 21:18:24, Igor Mammedov wrote: > > > On Tue, 26 Jan 2021 13:33:52 -0800 > > > Ben Widawsky <b...@bwidawsk.net> wrote: > > > > > > > I'm working on CXL 2.0 type 3 memory devices [1]. In short, these are > > > > PCIe devices > > > > that have persistent memory on them. As such, it would be nice to > > > > inherit from > > > > both a PCI_DEVICE class as well as an NVDIMM device class. > > > > > > > > Truth be told, using TYPE_MEMORY_DEVICE as the interface does provide > > > > most of > > > > what I need. > > > could you be more specific on what you need from it? > > > > > > > I'm trying to register my persistent memory as normal system memory. I > > assume > > it's required that I implement the memory interface to do that. If it's not, > > that's fine too. > > > > For reference: > > https://gitlab.com/bwidawsk/qemu/-/blob/cxl-2.0v3/hw/mem/cxl_type3.c > > if you use TYPE_MEMORY_DEVICE machinery, then address/(max)size a device > takes in > hotplug ram window, is fixed at device creation time. > If you use PCI BAR to map memory, it should be possible to reprogram BAR > anywhere in PCI address space at runtime. >
This is not part of the PCI address space. I believe there will be quite a bit of work to support hotplug properly for CXL devices, but I believe making it a PCI BAR is the wrong approach. If you're not yet familiar with the spec, it might make some sense to take a look as I think I'm not doing a good job conveying what this hardware is. https://www.computeexpresslink.org/download-the-specification > > > >I'm wondering what the best way to handle this is. Currently, the > > > > only thing NVDIMM class provides is write/read_label_data, this is > > > > driven by > > > > _DSM. For CXL, the mechanism to read/write the equivalent area is not > > > > done via > > > > _DSM, but done directly via a mailbox interface. However, the intent is > > > > the > > > > same, and so utilizing similar code seems ideal. > > > > > > > > If there's a desire to unify these code paths, I'd need something like > > > > multiple > > > > inheritance. I'm looking for some feedback here on how to do it. > > > > > > > > Thanks. > > > > Ben > > > > > > > > [1]: > > > > https://lore.kernel.org/qemu-devel/20210105165323.783725-1-ben.widaw...@intel.com/ > > > > > > > > > >
