Re: [RFC V2 09/10] hw/cxl: Wire SVC and Dev3 capability to CXL Type 3 device

[Junjie Cao <junjie.cao@intel.com>]

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