On Thu, 06 Oct 2022, Jonathan Cameron wrote:
3) Upstream linux drivers haven't touched ram configurations yet. I
just configured this with Dan Williams yesterday on IRC. My
understanding is that it's been worked on but nothing has been
upstreamed, in part because there are only a very small set of devices
available to developers at the moment.
There was an offer of similar volatile memory QEMU emulation in the
session on QEMU CXL at Linux Plumbers. That will look something like you have
here and maybe reflects that someone has hardware as well...
Yeah, putting this back together was on my todo list, but happy to see
patches are out. Recollecting my thoughts on this, my original approach
was also to support only volatile or persistent capacities, but through
two backends, and thus two address spaces. Afaik the last idea that was
discussed on IRC in this regard was to do it with a single backend along
with a pmem_offset=N boundary (0 or 100% for example for one type or the
other) tunnable.
...
Seems a little odd to use two memory backends. Of what use is it to the
software developers, it should be completely transparent to them, right?
The only thing I can think of is maybe reset mechanics for volatile
regions being set differently than persistent regions, but even then it
seems simple enough to just emulate the behavior and use a single
backing device.
It's a very convenient path as lets us define sizes and things from the
actual memdev rather than duplicating all the configuration in multiple
devices. If it weren't for the ability to change the allocations at runtime
I'd definitely say this was the best path. That corner makes it complex
but I'd still like the simplicity of you throw a backend at the device
and we set up all the description on basis that backend is what we want
to use.
Agreed.
...
> > > Example command lines
> > > ---------------------
> > > -A very simple setup with just one directly attached CXL Type 3 device::
> > > +A very simple setup with just one directly attached CXL Type 3
Persistent Memory device::
> > >
> > > qemu-system-aarch64 -M virt,gic-version=3,cxl=on -m
4g,maxmem=8G,slots=8 -cpu max \
> > > ...
> > > @@ -308,7 +308,18 @@ A very simple setup with just one directly attached
CXL Type 3 device::
> > > -object
memory-backend-file,id=cxl-lsa1,share=on,mem-path=/tmp/lsa.raw,size=256M \
> > > -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \
> > > -device cxl-rp,port=0,bus=cxl.1,id=root_port13,chassis=0,slot=2 \
> > > - -device
cxl-type3,bus=root_port13,memdev=cxl-mem1,lsa=cxl-lsa1,id=cxl-pmem0 \
> > > + -device
cxl-type3,bus=root_port13,pmem=true,memdev=cxl-mem1,lsa=cxl-lsa1,id=cxl-pmem0 \
So regardless of the interface we end up with, volatile and lsa parameters
should be mutually exclusive.
Thanks,
Davidlohr
