Re: Cxl devel!

[Maverickk 78]

Hi Jonathan,

Thanks for the response, effort and time you spent to list down the
TODOs in CXL space.

I just started understanding CXL2.0, am part of a startup developing a
CXL2.0 switch to build
compostable architecture, it's been 6 weeks.

As part of it I have built QEMU and configured with CXL devices as
documented in
https://stevescargall.com/blog/2022/01/20/how-to-emulate-cxl-devices-using-kvm-and-qemu/

And use your PoC code to understand the FMAPI & MCTP message flow.

Going forward I will ramp-up on the existing support in QEMU,
especially regarding the points you listed and
get used to the development/debug/test workflow, maybe I need 2-3
weeks to process all the information
you provided.

Any cheatsheets from your side will be helpful and it will help me
catch up soon.

Looking forward to working with you.

Regards
Raghu



On Tue, 28 Mar 2023 at 18:29, Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> 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
>