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

[Jonathan Cameron via <qemu-devel@nongnu.org>]

> > but i'm not sure of what to do with this info.  We have some proof
> > that real hardware works with this no problem, and the only difference
> > is that the EFI/bios/firmware is setting the memory regions as `usable`
> > or `soft reserved`, which would imply the EDK2 is the blocker here
> > regardless of the OS driver status.
> > 
> > But I'd seen elsewhere you had gotten some of this working, and I'm
> > failing to get anything working at the moment.  If you have any input i
> > would greatly appreciate the help.
> > 
> > QEMU config:
> > 
> > /opt/qemu-cxl2/bin/qemu-system-x86_64 \
> > -drive file=/var/lib/libvirt/images/cxl.qcow2,format=qcow2,index=0,media=d\
> > -m 2G,slots=4,maxmem=4G \
> > -smp 4 \
> > -machine type=q35,accel=kvm,cxl=on \
> > -enable-kvm \
> > -nographic \
> > -device pxb-cxl,id=cxl.0,bus=pcie.0,bus_nr=52 \
> > -device cxl-rp,id=rp0,bus=cxl.0,chassis=0,slot=0 \
> > -object memory-backend-file,id=cxl-mem0,mem-path=/tmp/cxl-mem0,size=256M \
> > -object memory-backend-file,id=lsa0,mem-path=/tmp/cxl-lsa0,size=256M \
> > -device cxl-type3,bus=rp0,pmem=true,memdev=cxl-mem0,lsa=lsa0,id=cxl-pmem0 \
> > -M cxl-fmw.0.targets.0=cxl.0,cxl-fmw.0.size=256M
> > 
> > I'd seen on the lists that you had seen issues with single-rp setups,
> > but no combination of configuration I've tried (including all the ones
> > in the docs and tests) lead to a successful region creation with
> > `cxl create-region`  
> 
> Hmm. Let me have a play.  I've not run x86 tests for a while so
> perhaps something is missing there.
> 
> I'm carrying a patch to override check_last_peer() in
> cxl_port_setup_targets() as that is wrong for some combinations,
> but that doesn't look like it's related to what you are seeing.

I'm not sure if it's relevant, but turned out I'd forgotten I'm carrying 3
patches that aren't upstream (and one is a horrible hack).

Hack: https://lore.kernel.org/linux-cxl/20220819094655.000005ed@huawei.com/
Shouldn't affect a simple case like this...

https://lore.kernel.org/linux-cxl/20220819093133.00006c22@huawei.com/T/#t
(Dan's version)

https://lore.kernel.org/linux-cxl/20220815154044.24733-1-Jonathan.Cameron@huawei.com/T/#t

For writes to work you will currently need two rps (nothing on the second is fine)
as we still haven't resolved if the kernel should support an HDM decoder on
a host bridge with one port.  I think it should (Spec allows it), others unconvinced.

Note I haven't shifted over to x86 yet so may still be something different from
arm64.

Jonathan


> 
> >   
> > > > 
> > > > 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...
> > >     
> > 
> > I saw that, and I figured I'd start the conversation by pushing
> > something :].  
> 
>