> -----Original Message-----
> From: Eric Auger <[email protected]>
> Sent: Monday, November 18, 2024 10:02 AM
> To: Shameerali Kolothum Thodi
> <[email protected]>; [email protected];
> [email protected]
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; Linuxarm <[email protected]>; Wangzhou (B)
> <[email protected]>; jiangkunkun <[email protected]>;
> Jonathan Cameron <[email protected]>;
> [email protected]
> Subject: Re: [RFC PATCH 4/5] hw/arm/virt-acpi-build: Build IORT with
> multiple SMMU nodes
>
> > /* Number of IORT Nodes */
> > @@ -342,10 +356,9 @@ build_iort(GArray *table_data, BIOSLinker
> *linker, VirtMachineState *vms)
> > /* GIC ITS Identifier Array */
> > build_append_int_noprefix(table_data, 0 /* MADT translation_id */,
> 4);
> >
> > - if (vms->iommu == VIRT_IOMMU_SMMUV3) {
> > - int irq = vms->irqmap[VIRT_SMMU] + ARM_SPI_BASE;
> > + for (i = 0; i < num_smmus; i++) {
> > + smmu_offset[i] = table_data->len - table.table_offset;
> >
> I would have expected changes in the smmu idmap has well. If a given
> SMMU instance now protects a given bus hierarchy shouldn't it be
> reflected in a differentiated SMMU idmap for each of them (RID subset of
> SMMU->pci-bus mapping to a specific IORT SMMU node)? How is it done
> currently?
I thought that smmu_idmaps will be handled by this ?
object_child_foreach_recursive(object_get_root(),
iort_host_bridges, smmu_idmaps);
But it is possible that, there is a bug in this IORT generation here as I am not
able to hot add devices. It looks like the pciehp interrupt is not
generated/received
for some reason. Nicolin[0] is suspecting the min/max bus range in
iort_host_bridges() may not leave enough ranges for hot add later.
Cold plugging devices to different SMMUv3/pcie-pxb seems to be alright.
I will debug that soon.
Thanks,
Shameer
[0] https://lore.kernel.org/qemu-devel/ZzPd1F%2FUA2MKMbwl@Asurada-Nvidia/
