Re: [ndctl PATCH 0/3] Enable CXL protocol testing

[Alison Schofield <alison.schofield@intel.com>]

On Wed, Apr 08, 2026 at 04:39:41PM -0500, Cheatham, Benjamin wrote:
> On 4/8/2026 3:32 PM, Terry Bowman wrote:
> > Current CXL error injection (EINJ) only supports Root Port protocol error
> > injection but a method to test all CXL devices is needed. This series
> > outlines methods to update both the kernel and the 'aer-inject' tool-without
> > relying on EINJ-to enable CXL RAS protocol error handling across all CXL
> > devices.
> > 
> 
> This functionality should probably be added to the inject-protocol-error subcommand
> instead of spread out across the directory as a bunch of scripts + patches. The command
> is only set up for protocol error injection, but I don't think it would be *too* hard
> to extend.
> 
> I think the first thing you have to do is expand the accepted device types to include ports and
> memdevs instead of just dports. That should be simple enough, there are already helpers to find
> both based on sbdf, name, etc. Then, you'd need to change the interface used to inject the error
> based on device type (is it a root port? then use EINJ, otherwise use aer-inject). All that's
> left at that point is to actually call the aer-inject command with the correct options (and
> update the documentation/help messages).
> 
> I would be happy to help with any of the above if you agree with the direction, just let me
> know!

Terry & Ben,

Terry thanks for sharing all this!

Reading patches and Bens comments and trying to understand the pieces
needed to make this reusable. Help me out here:

1) expand our (Bens recently added) cxl-cli inject-protocol-error cmds
   - to handle new types
   - to route to aer-inject tool

2) make aer-inject tool handle corr/uncor internal errors
   https://github.com/intel/aer-inject

3) make cxl/test capable of do special RAS status
   - maybe a wrapper

4) then we write scripts that run under cxl/test, require aer-inject
tool AND what else do they require?  Does this require CXL QEMU devices?
Are they doing something special in this recipe? Is this something our
CXL Test mock devices can fake?

Above is my quick attempt to understand. Please advise me.

--Alison


> 
> Thanks,
> Ben