Re: [RFC PATCH 10/17] misc/i2c_mctp_cxl: Initial device emulation

[Jonathan Cameron via <qemu-devel@nongnu.org>]

On Tue, 18 Jul 2023 17:30:57 -0400
Gregory Price <gregory.price@memverge.com> wrote:

> On Mon, Jul 17, 2023 at 06:16:39PM +0100, Jonathan Cameron wrote:
> > @@ -397,8 +401,9 @@ struct CXLType3Dev {
> >      AddressSpace hostpmem_as;
> >      CXLComponentState cxl_cstate;
> >      CXLDeviceState cxl_dstate;
> > -    CXLCCI cci;
> > -    
> > +    CXLCCI cci; /* Primary PCI mailbox CCI */
> > +    CXLCCI oob_mctp_cci; /* Initialized only if targetted */
> > +  
> 
> I've been humming and hawing over this on the MHD stuff because I wanted
> to figure out how to "add a CCI command" to a type-3 device without
> either having a billion definitions for CCI command sets - or doing
> something like this.
> 
> I don't hate this design pattern, I just want to ask whether your
> intent is to end up with CXLType3Dev hosting many CXLCCI's based on what
> wrapper types you have. 
> 
> Example: a type-3 device with mctp pass through and the MHD command set
> 
> CXLType3Dev {
>     ...
>     CXLCCI cci;
>     CXLCCI oob_mctp_cci;
>     CXLCCI mhd_cci;
>     ...
> }

Yes - that's what I was thinking.  In some cases a CCI may be accessed by
tunneling on a different CCI on the same device as well as the option
of tunneling to different devices.

So far the set that we'll end up with isn't too large. And if some aren't
used for a given instantiation that's fine if it keeps the code simple.
We may end up with other MCTP buses and to keep things consistent each one
will need it's own target CXLCCI. If we need to rethink and make it dynamic
to some degree we can look at it later.

> 
> Instantiate:
> -device cxl-type3,bus=swport0,memdev=cxl-mem1,id=cxl-pmem1,lsa=cxl-lsa1,sn=3 
> -device i2c_mctp_cxl,bus=aspeed.i2c.bus.0,address=5,target=cxl-pmem1
> -device cxl-mhd,target=cxl-pmem1,...whatever else...

Not sure on this - it may be implicit in creating an MHD rather than requiring
a command line to target through.  Depends on what the MHD creation code
looks like - but this is definitely a possibility.

> 
> where the MHD code is contained within its own type/file, and the type3
> device hosts the CCI for it.  Similar to how you've implemented the MTCP
> stuff here.
> 
> The reason I ask is because certain CCI's don't necessarily get
> associated with "a bus" so much as "a device".  the MHD example - it's
> still part of "the device", but it's optional.   

For emulation I don't think we care if it's optional. I think we implement
it whatever and if it is not accessed that is fine.

> So does it make sense
> to create this wrapper without a bus association, or to just pile it on
> top CXLType3Dev and have to duplicate the code across any other
> multi-headed devices that folks may conjur up?

Piling it on top of CXLType3Dev was what I was thinking. We can rethink if
there other multi-headed devices using similar interfaces.

Jonathan


> 
> ~Gregory