Re: [RFC PATCH v3 21/31] hw/cxl/device: Add a memory device (8.2.8.5)

Ben Widawsky
2021-02-02T15:18:35Z

On 21-02-02 08:26:14, Eric Blake wrote:
> On 2/1/21 6:59 PM, Ben Widawsky wrote:
> > A CXL memory device (AKA Type 3) is a CXL component that contains some
> > combination of volatile and persistent memory. It also implements the
> > previously defined mailbox interface as well as the memory device
> > firmware interface.
> >
> > Although the memory device is configured like a normal PCIe device, the
> > memory traffic is on an entirely separate bus conceptually (using the
> > same physical wires as PCIe, but different protocol).
> >
> > The guest physical address for the memory device is part of a larger
> > window which is owned by the platform. Currently, this is hardcoded as
> > an object property on host bridge (PXB) creation, but that will need to
> > change for interleaving.
> >
> > The following example will create a 256M device in a 512M window:
> > -object "memory-backend-file,id=cxl-mem1,share,mem-path=cxl-type3,size=512M"
> > -device "cxl-type3,bus=rp0,memdev=cxl-mem1,id=cxl-pmem0,size=256M"
> >
> > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> > ---
>
> > +++ b/qapi/machine.json
> > @@ -1394,6 +1394,7 @@
> > { 'union': 'MemoryDeviceInfo',
> > 'data': { 'dimm': 'PCDIMMDeviceInfo',
> > 'nvdimm': 'PCDIMMDeviceInfo',
> > + 'cxl': 'PCDIMMDeviceInfo',
> > 'virtio-pmem': 'VirtioPMEMDeviceInfo',
> > 'virtio-mem': 'VirtioMEMDeviceInfo'
> > }
>
> Missing documentation that 'cxl' was introduced in 6.0. Also, is it
> worth keeping the branches of this union in lexicographic order?
>

Sure.

As discussed on the list previously, I think more thought needs to be put in
here, and I could really use some input.

A CXL type3 memory device can have both persistent and volatile capacity. As
such a single PCDIMMDeviceInfo I believe is insufficient. The current code
supports persistent memory only, so this is fine for now.

I'd guess my best bet is to create a new CXLType3DeviceInfo, but I'm not
entirely sure of all the implications that has.

Any advice?

> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc. +1-919-301-3226
> Virtualization: qemu.org | libvirt.org
>
>