Re: Cxl devel!

[Jonathan Cameron]

On Fri, 24 Mar 2023 04:32:52 +0530
Maverickk 78 <maverickk1778@gmail.com> wrote:

> Hello Jonathan
> 
> Raghu here, I'm going over your cxl patches for past few days, it's very
> impressive.
> 
> I want to get involved and contribute in your endeavor, may be bits &
> pieces to start.
> 
> If you're specific trivial task(cvl/pcie/fm) about cxl, please let me know.
> 
> Regards
> Raghu
> 

Hi Raghu,

Great that you are interested in getting involved.

As to suggestions for what to do, it's depends on what interests you.
I'll list some broad categories and hopefully we can focus in on stuff.

Following is brainstorming on the spot, so I've probably forgotten lots
of things.   There is an out of date todo at:
https://gitlab.com/jic23/qemu/-/wikis/TODO%20list

Smallish tasks.
1) Increase fidelity of emulation.  In many places we take short cuts in
   the interests of supporting 'enough' to be able to test kernel code against..
   A classic example of this is we don't perform any of the checks we should be
   on HDM decoders.  Tightening those restrictions up would be great. Typically 
that
   involves tweaking the kernel code to try and do 'wrong' things.
   There are some other examples of this on gitlab.com/jic23/qemu around 
locking of
   registers. This is rarely as high priority as 'new features' but we will 
want to
   tidy up all these loose corners eventually.
2) Missing features.  An example of this is the security related stuff that 
went into
   the kernel recently.  Whilst that is fairly easy to check using the cxl 
mocking
   driver in the kernel, I'd also like to see a QEMU implementation.
   Some of the big features don't interact as they should.  For instance we 
don't report
   poison list overflow via the event log yet.  It would be great to get this 
all working
   rather than requiring injection of poison and the event as currently needed 
(not all
   upstream yet).
3) Cleanup some of the existing emulation that we haven't upstreamed yet.
   - CPMU. Main challenge with this is finding balance between insane 
commandlines
     and flexibility.  Right now the code on gitlab.com/jic23/qemu (cxl-<latest 
data>)
     provides a fairly random set of counters that were handy for testing 
corners
     of the driver that's at v3 on the kernel mailing lists.
   - Review and testing of the stuff that is on my tree (all been on list I 
think) but
     not yet at the top. Fixing up problems with that in advance will save us 
time
     when proposing them for upstream.
   - SPDM / CMA.  Right now this relies on a connection to SPDM-emu.  I'd like 
to explore
     if we can use libspdm as a library instead.  Last time I checked this 
looked non
     trivial but the dmtf tools team are keen to help.


Bigger stuff - note that people are already looking at some of these but they
may be interested in some help.
1) An example type 2 device.  We'd probably have to invent something along the
   lines of a simple copy offload engine.  The intent being to prove out that
   the kernel code works.  Dan has some stuff on the git.kernel.org tree to 
support
   type 2 device.
2) Tests.  So far we test the bios table generation and that we can start qemu 
with
   different topologies. I'd love to see a test that actually brings up a 
region and
   tests some reading and writing + ideally looks at result in memory devices 
to check
   everything worked.
3) Dynamic Capacity Devices - some stuff on going related to this, but there is 
a lot
   to do.  Main focus today is on MHDs.   Perhaps look at the very earl code 
posted
   for switch CCIs.  We have a lot of work to do in kernel for this stuff as 
well.
4) MCTP CCI.  I posted a PoC for this a long time back.  It works but we'd need 
to figure
   out how to wire it up sensibly.

Jonathan