On Wed, 28 Apr 2021 18:26:10 +0100 Lorenzo Pieralisi lorenzo.pieralisi@arm.com wrote:
On Wed, Apr 07, 2021 at 05:35:58PM +0100, Jonathan Cameron wrote:
On Wed, 7 Apr 2021 17:14:05 +0100 Lorenzo Pieralisi lorenzo.pieralisi@arm.com wrote:
On Mon, Mar 15, 2021 at 04:55:50PM +0000, Jonathan Cameron wrote:
On Mon, 15 Mar 2021 16:42:34 +0000 Lorenzo Pieralisi via Linaro-open-discussions linaro-open-discussions@op-lists.linaro.org wrote:
On Mon, Mar 15, 2021 at 01:00:19AM +0000, Jammy Zhou via Linaro-open-discussions wrote:
Hi all,
We're going to have the LOD meeting in one week, currently we don't have any topic proposed yet. Please let me know if you have something to discuss.
I would be glad to have a follow-up with Jonathan on CXL expansion memory on arm64 if possible, hopefully I can read up in the meanwhile to get up to speed on the matter.
I'm always happy to talk on this topic :) There is a related discussion around the (code-first) proposal to generalize GI usage to enable some CXL use cases that we might also be able to have a useful discussion about:
https://lore.kernel.org/linux-acpi/CAPcyv4gmd_cygXK0PpGkXmJLC3_ctEpRvpi5P-Qc...
Hi Jonathan,
Hi Lorenzo,
catching up on this - may I ask you please what's the best option/repo to pull QEmu changes and command script to test the current CXL (and PCI/DOE) kernel patches ?
I'd leave the DOE side of things for a few days as I'm just going through testing a rewrite. Should have something out shortly if nothing much comes up to distract me.
Qemu wise
https://gitlab.com/bwidawsk/qemu/-/commits/cxl-2.0v4/ with Chris Browy's DOE patches off list but there is an issue with that around memcpy_toio() and mailbox_reg_read() not providing the byte wise accessor. There are various possible fixes for that, but you want the lazy one add
case 1: return cxl_dstate->mbox_reg_state[offset]; to the obvious place in hw/cxl/cxl-device-utils.c / mailbox_reg_read() and change .min_access_size = 4 to 1 in mailbox_ops.impl.min_access_size.
Ben isn't keen on that fix, because we only need it because of what looks to be a bug in QEMU in the first place (or wrong docs).
https://lore.kernel.org/qemu-devel/20210218165010.00004bce@Huawei.com/ gives details on that.
I haven't yet tested or reviewed Chris' latest version of DOE emulation yet though.
I am struggling to bring this up. Are you running a x86 VMM or aarch64 emulation environment ? Asking because with my usual scripts and adding a simple CXL hierarchy in QEmu as per:
https://lwn.net/Articles/846061/
is not really working for me. If you have a command script to share it is welcome - looking forward to testing and reviewing the DOE patches.
I'm mostly running aarch64 emulated on top of x86 - I should sanity check it on KVM at somepoint.
I'm copy typing this across machines, so whilst I hope there are no typos there might be. I've stripped back my normal case (which has a big complex topology to try and hit corner cases...) First I'd suggest checking that have right EDK2 etc to bring up pxb with normal pci rp and a device.
qemu-system-aarch64 -M virt,nvdimm=on -m 4g,maxmem=8G,slots=2 -cpu max -smp 4 \ -kernel Image \ -drive if=non,file=full.qcow2,format=qcow2,id=hd \ -nographic -no-reboot -append 'earlycon root=/dev/vda2 fsck.mode=skip' \ -bios QEMU_EFI.fd \ #note this needs the pxb enablement patches -maybe upstream by now. -object memory-backend-ram,size=4G,id=mem0 \ -numa node,nodeid=0,cpus=0-3,memdev=mem0 \ -object memory-backend-file,id=cxl-meme1,share,mem-path=/tmp/cxltest.raw,size=2G,align=2G \ -device pxb-cxl,bus_nr=128,id=cxl1.1,uid=0,len-window-base=1,window-base[0]=0x4c0000000,memdev[0]=cxl-mem1 \ # above range just needs to not trample on anything. -device cxl-rp,bus=cxl1.1,id=root_port13,chassis=0,slot=1 \ -device cxl-type3,bus=root_port13,memdev=cxl-mem1,lsa=cxl-mem1,id=cxl-pmem0,size=2G
Hmm. Perhaps I should just write a blog post and include all the random corners needed to get this up. Problem then is I'd actually have to figure out what some of the parts are doing having long forgotten the answer so might take a day or two.
In meantime we can carry on here.
J
Thanks, Lorenzo
I remember reading there is an IRC channel cxl related (#cxl @ OFTC ?) - if there is happy to switch to it rather than bothering you with these queries.
I tend to avoid IRC because of potential auditing issues (no logs) so email is the way to go.
Thanks a lot ! Lorenzo
As there are some US folks who are interested in this topic (but super busy), can we do a straw poll of whether any of them can make a call on Monday?
If not go for a more China/Europe friendly time?
We had a few more topics brewing, but I'm not sure they will be in a state to discuss next week (or to give anyone else time to think about them in advance).
Obviously good to touch on any updates to older topics as well if anyone has any!
Jonathan
Lorenzo