Re: [RFC V2 08/10] hw/pci: Add PCIe Device3 capability support

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

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