Hi Shrihari,
On Wed, 26 Aug 2026 11:04:09 +0530, Shrihari E S wrote:
> + if (ct3d->svc) {
> + /* SVC capability of the type3 device */
> + rc = pcie_svc_cap_init(pci_dev, 0x200 + PCI_ERR_SIZEOF, errp);
> + if ((rc >= 0) && ct3d->flitmode && ct3d->uio_comp_capable) {
The cover letter says x-uio depends on x-svc and x-256b-flit, but this
only gates the config space capabilities. ct3d_reset() passes
ct3d->uio_comp_capable straight to cxl_component_register_init_common(),
so those dependencies don't reach the component registers. I checked:
a type3 with x-uio=on and neither x-svc nor x-256b-flit boots silently
and its HDM Decoder Capability reads 0x00043b12 -- UIO set, UIO
decoder count filled -- with no SVC or Dev3 capability in config
space, and hdm_decoder_commit() will then latch ct3d->uio_enabled from
the guest write. Failing realize ("x-uio requires x-svc and
x-256b-flit") would keep the device consistent; alternatively deriving
one uio gate at realize and using it for both the capabilities and the
register init would do the same.
It's asymmetric the other way as well: there's no x-uio on the ports,
and x-256b-flit defaults to on for a cxl-rp, so x-svc=on alone is
enough -- a cxl-rp with just x-svc=on reads 0x00042312 -- while the
type3 has to spell it out. That assumes root ports keep the bit at
all; see my note on 5/10.
Related: ct3d->uio_enabled, the dev->exp.svc flags and the two
pcie_dev3_*_enabled() helpers are written but never read anywhere in
the series. Same as on 3/10, I'd land them with the code that consumes
them -- here that's the data-plane series.
With the full docs topology (patch 10's example) the layout itself
looks good: on the type3 device SVC lands at 0x248 behind AER and Dev3
at 0x2bc, chain intact, and Dev3 advertises UIO/14-bit-tag completer
with Segment Captured tracking flit mode.
Many thanks,
Junjie
