Re: CXL emulation in QEMU contribution

[Jonathan Cameron]

On Wed, 12 Oct 2022 15:43:35 -0700
"Viacheslav A.Dubeyko" <viacheslav.dubeyko@bytedance.com> wrote:

> Hi Jonathan,

Hi Slava,

Thanks for sending this.
> 
> As we agreed, I am moving our discussion into public mailing list.
> 

> So, I would like to contribute to QEMU emulation of CXL memory
> support. And I would like to see a TODO list. I hope this list could
> be useful not only for me. As far as I can see, we can summarize:

Absolutely agree on need for a TODO now there are multiple groups involved.
https://gitlab.com/jic23/qemu/-/wikis/TODO-list
is my starting point on this on basis a wiki is a cheap and cheerful way
to track this.

> 

> 1) Moving towards emulation of everything we need for Dynamic Capacity.
>   a) Switch CCI - have a PoC but not yet doing tunneling to Type 3 EPs.

See below. Initial support pushed out to gitlab. Doesn't do much yet beyond
walk some basic info for a static switch.

>   b) Userspace tool to fake enough FM role that we can drive dynamics 

Currently I'm using the IOCTL path used by the cxl tool in ndctl.
I would definitely not describe my test program as 'good userspace code'
though :)

>   c) Also need to do CXL 2.0 style HP of LDs on MLD devices (some demand
>   for this to driver virtualization migration usecases)
>   d) DCD implementation etc on the type 3 device.

May want to do this on multiport devices first. 

> 2) Lots of smaller features from CXL 3.0 such as setting up BI.
> 3) Enough to test P2P UIO flows - probably need to invent an accelerator
>   with appropriate support to test that - DMA engine or similar.
> 4) Bunch of small features:
>   a) Multiple HDM decoders.

This is a fairly urgent feature to test mixed volatile / non volatile stuff
using Gregory Price's emulation of volatile for the type 3 device.

>   b) Poisoning.  Right now we have prototype, but it's not wired up
> to actually report poison on reads.

The command handling stuff is on the tree below, but this needs exploring
on qemu side. I'm not even sure what 'poison' would look like.

>   c) CXL non-function map DVSEC. Given QEMU lets you add any function
> to a given device by just setting  the bus to be the same as another,
> this is a bit fiddly because we need to updated it late in the QEMU
> bring up, or possibly easier to do it at read time (that may well be
> easier).

This one should be a fairly small task for anyone interested.  Not super
high priority though as kernel driver doesn't care yet ;)

>   d) Most useful of all, but most boring perhaps is review of what's
> already waiting for upstreaming.

For this one I've pushed out what I currently have queued up.
https://gitlab.com/jic23/qemu/-/commits/cxl-2022-10-13

I'll also add that stuff to the todo list
I'm aware of two other series that have been posted.

> 
> Please, correct me if I miss something. I believe we need to have a
> TODO list to collaborate efficiently. Any ideas what else can be added into 
> TODO list?

More error injection to support David Jiang's patch set testing.
Also, rather tangential to the rest but can wire up UEFI CPER record
reporting as well to test Smita Koralahalli's series.  I have old code
for doing that on aRM 64.

Also fairly high on what matters to me is arm64 support via DT to hopefully
help us get the arm-virt support upstream.  That's my daily test
platform so I'd rather not maintain it out of tree forever!

If anyone wants access to edit the page, DM me a registered gitlab ID and
I'll you to the project.

Jonathan

> 
> Thanks,
> Slava. 
>