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 <m...@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
