On Tue, 29 Jul 2025 09:54:39 -0700 Davidlohr Bueso <d...@stgolabs.net> wrote:
> Hello, > > The following allows support for component basic back invalidation discovery > and config, by exposing the BI routing table and decoder registers. Instead > of going the type2[1] route, this series proposes adding support for type3 > hdm-db, which allows a more direct way of supporting BI in qemu. > > Caveats/RFC: Just as in Ira's series, there is the question about the whole > topology > allowing BI, not just the endpoint device. That series left the rest of > topology > (dsp, rp) non-BI capable, for which any kernel counterpart testing would fail > when using type2, but at the same time is also consistent with flit 68B when > not > using a type2 device. > > This series blindly enables BI capabilities for ports even when no type3 > hdm-db > is being used. While it is handy, it is inconsistent with the driver seeing > 68B > and the BI registers in such cases. I've been going back and forth with > possible > workarounds, but don't really have a good answer, and this will ultimately > affect not only BI but all goodies that come with 256B flit. Any suggestions > welcome. Hi Davidlohr, We probably need to make this work like link width. That would push the control to the downstream port side and effectively 'trains' the link (really simple negotiation of capabilities). I don't think we care about more capable device plugged into a less capable upstream port, so a simple property for the type 3 device (and switch USP) should do the job. If we want to do the optimized flits we'll need a little more. So in short, make RP and downstream port always BI and 256bit flit capable, but 'fake' the training so if they are plugged into a EP or switch USP they report whatever that was configured for. So alongside your hdm-db property in patch 2, have a 256bit-flit property. Both of those have to apply for type 3 and the switch USP. Then we sanity check the combination works (i.e. hdm-db only if 256 bit flit) I think we need this fine grained control because we want to poke the corners where only parts of the tree are BI capable. So, precursor patch to enable 256bit flit mode then this stuff on top. Jonathan > > Patch 1: is lifted from Ira's series with some small (but non-trivial) > changes. > Patch 2: adds BI decoder/rt register support. > > Testing wise, this has passed relevant kernel side BI register IO flows and > setup. > > Applies against branch 'origin/cxl-2025-07-03' from the jic23 repository. > > Thanks! > > [1] > https://lore.kernel.org/linux-cxl/20230517-rfc-type2-dev-v1-0-6eb2e4709...@intel.com/ > > Davidlohr Bueso (1): > hw/cxl: Support Type3 HDM-DB > > Ira Weiny (1): > hw/cxl: Refactor component register initialization > > hw/cxl/cxl-component-utils.c | 206 ++++++++++++++++++++++++--------- > hw/mem/cxl_type3.c | 5 +- > include/hw/cxl/cxl_component.h | 87 +++++++++++--- > include/hw/cxl/cxl_device.h | 3 + > 4 files changed, 232 insertions(+), 69 deletions(-) > > -- > 2.39.5 >
