Hi Shrihari,
On Wed, 26 Aug 2026 11:04:08 +0530, Shrihari E S wrote:
> + /*
> + * A UIO requester must be able to issue DMA transactions.
> + * Enable PCI_COMMAND_MASTER in the PCI command register so the
> + * device's bus master bit is set when the requester capability
> + * is advertised.
> + */
> + pci_set_word(dev->config + PCI_COMMAND,
> + pci_get_word(dev->config + PCI_COMMAND) |
> + PCI_COMMAND_MASTER);
As posted this is dead code -- the series' only caller, in 09/10,
passes uio_req=false (the type3 is wired as completer only). If a
requester shows up later, the write still doesn't do what the comment
wants: pci_do_device_reset() clears the writable COMMAND bits, so on
cold boot the machine reset discards it before the guest runs. On a
hotplug path there is no bus reset, and pci_qdev_realize() ends in
pci_set_power() -> pci_set_enabled() -> pci_set_master(), so there the
write does take effect and the device surfaces with bus mastering
already on. Bus master enable stays under firmware/OS control; I'd
drop the write.
The Dev3 defines already exist in Linux, and they reached QEMU in
January: 49f6b93d0752 ("linux-headers: Update to Linux v6.19-rc1") put
PCI_EXT_CAP_ID_DEV3 0x2F into
include/standard-headers/linux/pci_regs.h. The cxl-2026-01-09-draft
base predates that sync, which is why this builds here; on master the
0x2f added to pcie_regs.h redefines it, and pcie.h pulls both headers
into the same TU, so that's a redefinition warning under the default
-Werror. The register offsets don't collide -- PCI_DEV3_CAP_OFFSET
here against the header's PCI_DEV3_CAP -- so PCI_EXT_CAP_ID_DEV3 is the
one to drop. SVC is the other case: 0x35 genuinely isn't in the kernel
header yet.
Many thanks,
Junjie
