On Tue, 23 Jun 2026 at 14:52, Utkarsh Singh <[email protected]> wrote:
>
> Add a user-configurable 'vid' parameter to allow overriding the default
> PCI vendor ID. This enables testing of vendor-specific quirks in guest
> operating systems.
>
> The parameter accepts a 16-bit hexadecimal value and defaults to Red Hat
> vendor ID (0x1b36). It is mutually exclusive with the 'use-intel-id' flag
> to prevent conflicting configurations.
>
> Suggested-by: Maurizio Lombardi <[email protected]>
> Suggested-by: John Meneghini <[email protected]>
> Signed-off-by: Utkarsh Singh <[email protected]>
> ---
> @@ -9401,6 +9406,7 @@ static const Property nvme_props[] = {
> DEFINE_PROP_STRING("serial", NvmeCtrl, params.serial),
> DEFINE_PROP_STRING("model", NvmeCtrl, params.model),
> DEFINE_PROP_STRING("firmware-version", NvmeCtrl,
> params.firmware_version),
> + DEFINE_PROP_UINT16("vid", NvmeCtrl, params.vid, PCI_VENDOR_ID_REDHAT),
Unless there's something NVME specific that makes "vid" the right
choice here, I think that "pci-vendor-id" or "vendor-id" would be the
more usual way to name this for QEMU (compare vfio "x-pci-vendor-id",
riscv iommu "vendor-id", the "vendor-id" field in the QGA
GuestDeviceIdPCI packet, "vendor-id" in xen_pvdevice).
Should we also have a "device-id" property here? Being able
to set the vendor-ID only seems unnecessarily limited, since
PCI IDs are a (vendor,device) tuple.
thanks
-- PMM
