Re: [PATCH] pci-ids.rst: Add Red Hat pci-id for AMD IOMMU device

[Suthikulpanit, Suravee]

On 3/6/2025 3:58 PM, Daniel P. Berrangé wrote:
> On Thu, Mar 06, 2025 at 09:11:53AM +0200, Yan Vugenfirer wrote:
> > On Wed, Mar 5, 2025 at 8:54 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > > On Tue, Mar 04, 2025 at 06:37:47PM +0000, Suravee Suthikulpanit wrote:
> > > > The QEMU-emulated AMD IOMMU PCI device is implemented based on the AMD
> > > I/O
> > > > Virtualization Technology (IOMMU) Specification [1]. The PCI id for this
> > > > device is platform-specific.
> > > >
> > > > Currently, the QEMU-emulated AMD IOMMU device is using AMD vendor id and
> > > > undefined device id.
> > >
> > > undefined?

Currently, QEMU is using vendor ID "1022" and device ID "0".

> > > > Therefore, change the vendor id to Red Hat and request a new
> > > QEMU-specific
> > > > device id.
> > >
> > > Won't the drivers fail to load then?
> >
> > Windows will not identify the device (it is a dummy device, without driver)
> > and SVVP certifications will fail as a result.
> > I suggest using ID that is already present in Windows machine.inf:
> > VEN_1002&DEV_5A23
>
>   Ven:  Advanced Micro Devices, Inc. [AMD/ATI]
>   Dev: RD890S/RD990 I/O Memory Management Unit (IOMMU)
>
> > VEN_1022&DEV_1419
>
>   Vendor:  Advanced Micro Devices, Inc. [AMD]
>   Dev: Family 15h (Models 10h-1fh) I/O Memory Management Unit
>
> Is our implementation semantically a match for the functionality
> in either of those real hardware devices ?
>
> We shouldn't use an existing hardware dev ID unless we intend to
> emulate its functionality as a precise match.

I agree. We should not use the "fake" ID unless we know for sure that 
the QEMU device is a match from the list of supported features and 
behavior (which might be implementation-specific on different 
platforms). Currently, this is not an exact match.

Linux does not care much about the PCI vendor/device ids since it uses 
the information in the IVRS table to probe for the device. Features are 
determined using the information in:
  * MMIO Offset 0030h IOMMU Extended Feature Register
  * MMIO Offset 01A0h IOMMU Extended Feature 2 Register

However, we can't guarantee how other OSes might be using these 
information for probing / loading drivers.

Thanks,
Suravee