Re: [PATCH v5 07/21] intel_iommu: Introduce a new structure VTDHostIOMMUDevice

[Nicolin Chen <nicolinc@nvidia.com>]

Hi Zhenzhong/Yi,

On Fri, Aug 22, 2025 at 02:40:45AM -0400, Zhenzhong Duan wrote:
> @@ -4371,6 +4374,7 @@ static bool vtd_dev_set_iommu_device(PCIBus *bus, void *opaque, int devfn,
>                                       HostIOMMUDevice *hiod, Error **errp)
>  {
>      IntelIOMMUState *s = opaque;
> +    VTDHostIOMMUDevice *vtd_hiod;
>      struct vtd_as_key key = {
>          .bus = bus,
>          .devfn = devfn,

I wonder if the bus/devfn here would always reflect the actual BDF
numbers in this function, on an x86 VM.

With ARM, when the device is attached to a pxb bus, the bus/devfn
here are both 0, so PCI_BUILD_BDF() using these two returns 0 too.

QEMU command for the device:
 -device pxb-pcie,id=pcie.1,bus_nr=1,bus=pcie.0 \
 -device arm-smmuv3,primary-bus=pcie.1,id=smmuv3.1,accel=on \
 -device pcie-root-port,id=pcie.port1,bus=pcie.1,chassis=1,io-reserve=0 \
 -device vfio-pci-nohotplug,host=0009:01:00.0,bus=pcie.port1,rombar=0,id=dev0,iommufd=iommufd0

QEMU log:
smmuv3_accel_set_iommu_device: bus=0, devfn=0, sid=0

The set_iommu_device op is invoked by vfio_pci_realize() where the
the BDF number won't get ready for this kind of PCI setup until a
later stage that I can't identify yet..

Given that VTD wants the BDF number too, I start to wonder whether
the set_iommu_device op is invoked in the right place or not..

Maybe VTD works because it saves the bus pointer v.s. bus_num(=0),
so its bus_num would be updated when later code calculates the BDF
number using the saved bus pointer (in the key). Nonetheless, the
saved devfn (in the key) is 0, which wouldn't be updated later as
the bus_num. So, if the device is supposed to have a devfn (!=0),
this wouldn't work?

Thanks
Nicolin