On Fri, 24 Mar 2023 04:32:52 +0530 Maverickk 78 <maverickk1...@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
