Hi Shrihari,
On Wed, 26 Aug 2026 11:04:07 +0530, Shrihari E S wrote:
> + if (p->svc) {
> + rc = pcie_svc_cap_init(d, CXL_UPSTREAM_PORT_SVC_OFFSET, errp);
> + if (p->flitmode && rc >= 0) {
> + usp->uio_capable = true;
> + }
> + }
This gate never opens on cxl-upstream: p->flitmode is the PCIEPort
field, but the USP's x-256b-flit property still targets its own
CXLUpstreamPort::flitmode rather than the field patch 1 moved to
PCIEPort, and nothing sets the PCIEPort one there. Everything else on
the USP (pcie_cap_fill_link_ep_usp(), the DVSEC status,
latch_registers()) reads usp->flitmode, so the port reports flit active
while uio_capable stays false. I read the HDM Decoder Capability
register back on the patch-10 example topology with
x-svc=on,x-256b-flit=on everywhere: the USP reads 0x00000382 -- UIO
clear, UIO decoder count 0 -- while cxl-rp reads 0x00042312 with UIO
set. A switch topology, the case the cover letter leads with, can't
advertise UIO through the USP. What worked for me was dropping the
CXLUpstreamPort copy so both readers take the PCIEPort field: with
that the USP reads 0x00042382 and nothing else in the topology moves.
I'd put it in 1/10, which left CXLUpstreamPort::flitmode behind while
its message says the refactor "allows all the derived ports ... to
use this property".
rpc->svc_offset is only set by gen_pcie_root_port; ioh3420,
pnv-phb-root-port and aspeed.pcie-root-port leave it 0, so
qemu-system-x86_64 -M q35 -display none -device ioh3420,x-svc=on
aborts:
../hw/pci/pcie.c:1140: pcie_add_capability: Assertion `offset >=
PCI_CONFIG_SPACE_SIZE' failed.
I'd either give them svc_offsets or fail realize with a proper error
when svc_offset is 0 and x-svc is set.
Neither of those shows up in make check. A qtest instantiating
ioh3420,x-svc=on would have caught the abort; the USP gate only shows
up in the component BAR, where I read it in the HDM Decoder Capability
register, so a chain walk wouldn't catch that one. Worth some
coverage for the two new capabilities.
The v1 SVC/AER collision is fixed -- I walked the extended chains
over ECAM: gen pcie-root-port has SVC at 0x150 after AER/ACS, cxl-rp's
four DVSECs moved out to 0x1c4 with SVC taking 0x150, and usp/dsp have
SVC at 0x148 with SN/DVSEC offsets shifted to match.
The DVSEC moves are unconditional, though. CXL_ROOT_PORT_DVSEC_OFFSET
and the usp/dsp equivalents are compile-time chains through
PCI_SVC_SIZEOF, so x-svc=off changes nothing: on a topology with no
x-svc anywhere I read cxl-rp DVSECs at 0x1c4 (0x150 on the base
branch), usp DSN at 0x1bc (0x148), dsp DVSEC at 0x1bc (0x148). That's
a config space change on existing CXL machines with no property to gate
it. Migration won't notice -- none of the CXL devices carries a
VMStateDescription, so their config space never reaches the stream --
but a guest on an unchanged machine type sees the DVSECs move across
QEMU versions, and there's no knob to hang a hw_compat entry on.
Many thanks,
Junjie
