Cxl devel!

Cxl devel!

[Maverickk 78]

[-- Attachment #1: Type: text/plain, Size: 281 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 532 bytes --]

Re: Cxl devel!

[Jonathan Cameron via]

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

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
>