Re: [PATCH 4/8] acpi_build: Use IOMMU pci device to build IOMMU device ID

[Alejandro Jimenez <alejandro.j.jimenez@oracle.com>]

On 8/27/26 2:18 AM, Sairaj Kodilkar wrote:
> On 8/1/2026 3: 17 AM, Alejandro Jimenez wrote: > > 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: >>
> 
> 
> On 8/1/2026 3:17 AM, Alejandro Jimenez wrote:
>> 
>> 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.
>> 
> 
> Hi alejandro,
> 
> Could you please share the steps and commands you used to change the bus
> number inside guest ? 

Sorry, my earlier statement was ambiguous/confusing because I used DeviceID
referring to the name of the IVRS field, but can also be taken as a portion
of the BDF. Let me try to be more clear:

I did not change the IOMMU device or function values (I don't think that is
currently possible). What I was able to change is the secondary bus number
of the pcie-root-port above the IOMMU. Then this changes the IOMMU BDF
(more specifically the Bus part of it).
I launched the guest with this topology:

  -device pcie-root-port,id=pcie-rp1,bus=pcie.0,addr=1c.0
  -device AMDVI-PCI,id=iommu-pci,bus=pcie-rp1,addr=0
  -device amd-iommu,dma-remap=on,xtsup=on,pci-id=iommu-pci

so firmware placed the IOMMU at 01:00.0, behind root port 00:1c.0.
Inside the guest:

# setpci -s 00:1c.0 PRIMARY_BUS SECONDARY_BUS SUBORDINATE_BUS
00
01
01

# setpci -s 00:1c.0 SECONDARY_BUS=02 SUBORDINATE_BUS=02

so the write is targeting the root port (pcie-rp1), not the IOMMU endpoint
itself. After that the IOMMU BDF in the guest is 02:00.0. IIUC the standard
lspci output displays the old BDF that has been cached by the guest OS when
enumerating the PCI devices, but setpci and lspci with option -H1 will do a
raw access and show the new BDF.

# lspci -H1 -Dnn
[...]
0000:02:00.0 IOMMU ... [1022:1419]

The IVRS table is not rebuilt following this guest write, which is I think
what MST is warning about.

Now we need to decide whether that operation I described above (which I
found researching ways to force the change to prove Michael's point) is
something that is considered valid. Perhaps there is a use for it that I am
not aware of, or perhaps it is just another way that a guest can break
itself and we are just supposed to let it.

I do see your explanation about why my initial proposal is too restrictive
for the future. I am just not sure yet what the right solution is.

Thank you,
Alejandro

I would like to run few tests around it but I am
> not able to change the PCI ID of the IOMMU with setpci command on root
> pci bridge.
> 
> Thanks
> Sairaj
>