Re: Concept of LD-ID in QEMU

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

On Wed, 7 Jun 2023 23:01:11 +0000
Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com> wrote:

> Hi,
> For DCD sideband there needs to be LD-ID. Is the following approach acceptable?

QEMU question so +CC qemu-devel

> 
>  -device cxl-type3,bus=swport0,volatile-memdev=vmem0,dc-memdev=vmem1,id=cxl-vmem0,num-dc-regions=2,ldid=0 \
>  -device cxl-type3,bus=swport0,volatile-memdev=vmem1,dc-memdev=vmem2,id=cxl-vmem1,num-dc-regions=2,ldid=1 \

Those will be PCI functions at this level so you can't do this until we have more advanced switch support
(it has to know about multiple VHs - right now we only support fixed config switches).  You could connect them
to different switch ports - effectively that will be what it looks like when we do emulate a configurable switch.

>  -device i2c_mctp_cxl,bus=aspeed.i2c.bus.0,address=24,target=cxl-vmem0,cxl-vmem1")
> 
> With this configuration, the same i2c device is handing both LDs and in FMAPI commands we use the LDID specified above.

This effectively becomes a partial implementation of either an MLD or an MH-SLD
To manage the actual memory access, those will almost certainly need a bunch of other shared
infrastructure.  So I'd ultimately expect the i2c_mctp_cxl device to target whatever
device represents that shared infrastructure - it might be a separate device or a 'lead' type 3 device.

So I'm not sure how this will fit together longer term.  We need same infrastructure
to work for a mailbox CCI on a MH-SLD/MLD as well and in that case there isn't a separate
device to which we can provide multiple targets as you've done in your proposal here.

So I think we need to work out how to handle all of (I've probably forgotten something)
X marks done or in progress.

X 1) i2c_mctp_cxl to an SLD (no PCI Mailbox definition for this one)
  2) i2c_mctp_cxl directly to an MLD (your case)
X 3) i2c_mctp_cxl to a fixed config switch (single fixed VH no MLD capable ports)
X 4) PCI mailbox via switch CCI device that fixed config switch (no MLD capable ports)
	Even with this simple design some fun things you can do.
  5) i2c_mctp_cxl to a configurable switch (probably a separate as yet to be defined management interface - that messes with hotplug)
  6) PCI mailbox via switch CCI to configurable switch (again to defined management interface).
  7) i2c_mctp_cxl to an MH-SLD - probably to which ever device also has support for
     tunneling to the FM owned LD via the PCI mailbox.
X 8) PCI mailbox on MH-SLD tunneling to the FM owned LD.
  9) i2c_mctp_cxl to an MH-MLD - similar to above - this one isn't that much more complex than MH-SLD case.
X 10) PCI mailbox to MH-MLD - similar to above.
  11) Tunneling via the switch CCI (then over PCI-VDM - though that detail isn't visible in QEMU) to an SLD
  12) Tunneling via the switch CCI (then PCI-VDM) to an MH-SLD and on to he FM owned LD.
  13) Tunneling via the switch CCI (then over PCI-VDM) to an MLD / MH-MLD
 
Current i2c_mctp_cxl covers 1 and 3
I'm part way through the tunnelling support for (8 and 100) - need to revisit and wire up the switch CCI PoC
properly which will give us 4.

2 needs MLD support in general which we could maybe make work with a static binding in a switch but that
  would be odd - so we probably need to emulate a configurable switch for that
5,6 need configurable switch
7 needs same as 2 plus tunneling part similar to 4
9 again probably configurable switch for the MLD part to make sense
11 is fairly straight forward - but not done yet.
12 also not too bad, but needs the MH-SLD part to be fleshed out (some work on going )
13 needs pretty much everything defined.

Trying to get the command line interface and device model right until we have PoC code
for a few more cases is going to be at most a draft of what it might look like.

So in short, lots to do.  For now feel free to hack whatever you need in to be able
to test the FM-API side of things, we can move that towards a clean command line definition
once we have one figured out!

Jonathan


> 
> Thanks,
> Shesha.