On Wed, 7 Jun 2023 23:01:11 +0000
Shesha Bhushan Sreenivasamurthy <shes...@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.
