Re: [PATCH RFC] hw/cxl: type 3 devices can now present volatile or persistent memory

From: Davidlohr Bueso <dave@stgolabs.net>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Gregory Price <gourry.memverge@gmail.com>,
	qemu-devel@nongnu.org, linux-cxl@vger.kernel.org,
	Alison Schofield <alison.schofield@intel.com>,
	"a.manzanares@samsung.com" <a.manzanares@samsung.com>,
	Ben Widawsky <bwidawsk@kernel.org>
Subject: Re: [PATCH RFC] hw/cxl: type 3 devices can now present volatile or persistent memory
Date: Fri, 7 Oct 2022 11:16:19 -0700	[thread overview]
Message-ID: <20221007181619.gumcab46ftnvhwbi@offworld> (raw)
In-Reply-To: <20221006174214.000059c7@huawei.com>

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