From: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
To: Sairaj Kodilkar <sarunkod@amd.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Cc: Ani Sinha <anisinha@redhat.com>,
Eduardo Habkost <eduardo@habkost.net>,
Igor Mammedov <imammedo@redhat.com>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
qemu-devel@nongnu.org, vasant.hegde@amd.com,
suravee.suthikulpanit@amd.com
Subject: Re: [PATCH 4/8] acpi_build: Use IOMMU pci device to build IOMMU device ID
Date: Fri, 31 Jul 2026 17:47:18 -0400 [thread overview]
Message-ID: <1df4e4b7-a89e-42c6-98d6-5631fdece7eb@oracle.com> (raw)
In-Reply-To: <79db539c-a89c-411f-8a34-ab49ca6b4bf2@amd.com>
On 7/31/26 8:32 AM, Sairaj Kodilkar wrote:
> On 7/31/2026 3: 20 PM, Michael S. Tsirkin wrote: > On Mon, May 11, 2026 at
> 06: 09: 33PM +0530, Sairaj Kodilkar wrote: >> Currently, build_amd_iommu()
> uses "addr" property to build the device ID for >> IOMMU device and
> advertise it
>
>
> On 7/31/2026 3:20 PM, Michael S. Tsirkin wrote:
>> On Mon, May 11, 2026 at 06:09:33PM +0530, Sairaj Kodilkar wrote:
>>> Currently, build_amd_iommu() uses "addr" property to build the device ID for
>>> IOMMU device and advertise it throught IVRS. But this property does not encode
>>> IOMMU bus. This will be a problem if IOMMU is attached to different bus.
>>> Hence use iommu pci device which provides bus, to build the IOMMU device ID.
>>>
>>> Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com>
>>> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
>>
>> But is this called after firmware has enumerated the pci bus?
>> And I guess OS better not change that bus number eh?
The above line sounds fairly threatening :) so I dug a bit more into the
details.
Short story: I tested placing the IOMMU behind a PCI bridge, which the
implementation currently allows, and the guest can (easily) change the bus
number. That changes the IOMMU BDF, so the DeviceID encoded in IVRS becomes
incorrect.
The spec doesn't forbid the above scenario, but "strongly recommends":
• An IOMMU should be a root-complex device (i.e., appear directly on the
bus at the top of the PCI tree hierarchy).
• Some system software may prohibit an IOMMU from appearing under a
PCI-to-PCI bridge.
(from Section 4.5 Software and Platform Firmware Implementation Issues)
While I don't know if that is the case in all HW implementations, my
Genoa/Zen4 system does follow the recommended topology i.e. it exposes all
of its 8 IOMMU functions directly on a PCI root bus, with no bridges.
So I think a reasonable choice is to enforce that an AMDVI-PCI device must
always be directly attached to a PCI root bus. There is precedent for this
in the virtio-iommu implementation already, the code change would be
basically the same in amdvi_pci_realize(), see:
e72cfabf4ef2 ("hw/virtio/virtio-iommu-pci: Enforce the device is plugged on
the root bus")
MST: does this address your concern?
Sairaj: Am I missing anything, perhaps from your unpublished patches, that
makes this approach non-viable?
Thank you,
Alejandro
>
> Hi Michael
>
> Yes, the ACPI function is called two times -- during qemu initialization
> and firmware writes. During first call, bus numbers are 0 and during
> second call, IVRS is created with bus number. This second IVRS
> overwrites the first one.
>
> Thanks
> Sairaj
>
>>> ---
>>> hw/i386/acpi-build.c | 12 ++++++------
>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
>>> index e4ad01eec037..718e3f546b18 100644
>>> --- a/hw/i386/acpi-build.c
>>> +++ b/hw/i386/acpi-build.c
>>> @@ -1752,10 +1752,13 @@ build_amd_iommu(GArray *table_data, BIOSLinker *linker, const char *oem_id,
>>> const char *oem_table_id)
>>> {
>>> AMDVIState *s = AMD_IOMMU_DEVICE(x86_iommu_get_default());
>>> + PCIDevice *iommu_dev = &(s->pci->dev);
>>> GArray *ivhd_blob = g_array_new(false, true, 1);
>>> AcpiTable table = { .sig = "IVRS", .rev = 1, .oem_id = oem_id,
>>> .oem_table_id = oem_table_id };
>>> uint64_t feature_report;
>>> + int iommu_bus = pci_bus_num(pci_get_bus(iommu_dev));
>>> + uint16_t iommu_devid = PCI_BUILD_BDF(iommu_bus, iommu_dev->devfn);
>>>
>>> acpi_table_begin(&table, table_data);
>>> /* IVinfo - IO virtualization information common to all
>>> @@ -1816,9 +1819,7 @@ build_amd_iommu(GArray *table_data, BIOSLinker *linker, const char *oem_id,
>>> /* IVHD length */
>>> build_append_int_noprefix(table_data, ivhd_blob->len + 24, 2);
>>> /* DeviceID */
>>> - build_append_int_noprefix(table_data,
>>> - object_property_get_int(OBJECT(s->pci), "addr",
>>> - &error_abort), 2);
>>> + build_append_int_noprefix(table_data, iommu_devid, 2);
>>> /* Capability offset */
>>> build_append_int_noprefix(table_data, s->pci->capab_offset, 2);
>>> /* IOMMU base address */
>>> @@ -1850,10 +1851,9 @@ build_amd_iommu(GArray *table_data, BIOSLinker *linker, const char *oem_id,
>>>
>>> /* IVHD length */
>>> build_append_int_noprefix(table_data, ivhd_blob->len + 40, 2);
>>> +
>>> /* DeviceID */
>>> - build_append_int_noprefix(table_data,
>>> - object_property_get_int(OBJECT(s->pci), "addr",
>>> - &error_abort), 2);
>>> + build_append_int_noprefix(table_data, iommu_devid, 2);
>>> /* Capability offset */
>>> build_append_int_noprefix(table_data, s->pci->capab_offset, 2);
>>> /* IOMMU base address */
>>> --
>>> 2.34.1
>>
>
next prev parent reply other threads:[~2026-07-31 21:48 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 12:39 [PATCH 0/8] acpi_build: Refactor and cleanup AMD IVRS build Sairaj Kodilkar
2026-05-11 12:39 ` [PATCH 1/8] tests/acpi: x86: Allow IVRS acpi table changes Sairaj Kodilkar
2026-05-11 12:39 ` [PATCH 2/8] amd_iommu: update PA, GVA and VA size macros Sairaj Kodilkar
2026-05-19 8:39 ` Vasant Hegde
2026-07-30 21:41 ` Alejandro Jimenez
2026-08-03 22:15 ` Michael S. Tsirkin
2026-05-11 12:39 ` [PATCH 3/8] amd_iommu: Return empty efr for stub call Sairaj Kodilkar
2026-07-30 21:45 ` Alejandro Jimenez
2026-05-11 12:39 ` [PATCH 4/8] acpi_build: Use IOMMU pci device to build IOMMU device ID Sairaj Kodilkar
2026-07-30 22:35 ` Alejandro Jimenez
2026-07-31 9:50 ` Michael S. Tsirkin
2026-07-31 12:32 ` Sairaj Kodilkar
2026-07-31 21:47 ` Alejandro Jimenez [this message]
2026-08-01 0:01 ` Michael S. Tsirkin
2026-08-04 5:01 ` Sairaj Kodilkar
2026-05-11 12:39 ` [PATCH 5/8] acpi_build: Introduce necessary macros and structs for AMD IOMMU IVRS Sairaj Kodilkar
2026-08-03 21:35 ` Alejandro Jimenez
2026-08-03 22:08 ` Michael S. Tsirkin
2026-05-11 12:39 ` [PATCH 6/8] acpi_build: Build IVRS feature report using extended feature register Sairaj Kodilkar
2026-05-19 8:43 ` Vasant Hegde
2026-05-11 12:39 ` [PATCH 7/8] acpi_build: Cleanup AMD IOMMU IVRS building Sairaj Kodilkar
2026-08-03 21:56 ` Michael S. Tsirkin
2026-08-03 22:10 ` Michael S. Tsirkin
2026-08-04 5:23 ` Sairaj Kodilkar
2026-05-11 12:39 ` [PATCH 8/8] tests/acpi: x86: update golden masters for IVRS Sairaj Kodilkar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1df4e4b7-a89e-42c6-98d6-5631fdece7eb@oracle.com \
--to=alejandro.j.jimenez@oracle.com \
--cc=anisinha@redhat.com \
--cc=eduardo@habkost.net \
--cc=imammedo@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=sarunkod@amd.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=vasant.hegde@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.