Re: [PATCH v2 1/6] hw/arm/smmuv3: Add support to associate a PCIe RC

[Markus Armbruster <armbru@redhat.com>]

Donald Dutile <ddutile@redhat.com> writes:

[...]

> In this series, an iommu/smmu needs to be placed -BETWEEN- a sysbus and a PCIe-tree,
> or step-wise, plug an smmuv3 into a sysbus, and a pcie tree/domain/RC into an SMMUv3.

RC = root complex?

> So, an smmu needs to be associated with a bus (tree), i.e., pcie.0, pcie.1...
> One could model it as a PCIe device, attached at the pcie-RC ... but that's not how it's modelled in ARM hw.

Physical ARM hardware?

Assuming the virtual devices and buses we're discussing model physical
devices and buses:

* What are the physical devices of interest?

* How are they wired together?  Which of the wires are buses, in
  particular PCI buses?

> SMMU's are discovered via ACPI tables.
>
> That leaves us back to the 'how to associate an SMMUv3 to a PCIe tree(RC)',
> and that leads me to the other discussion & format I saw btwn Eric & Shameer:
>  -device arm-smmv3,id=smmuv3.3
>  -device xxxx,smmuv3= smmuv3.3
> where one tags a (PCIe) device to an smmuv3(id), which is needed to build the (proper) IORT for (pcie-)device<->SMMUv3 associativity in a multi-SMMUv3 configuration.
>
> We could keep the bus=pcie.X option for the -device arm-smmuv3 to indicate that all PCIe devices connected to the pcie.0 tree go through that smmuv3;
> qdev would model/config as the smmuv3 is 'attached to pcie.0'... which it sorta is...  and I think the IORT build could associate all devices on pcie.0 to be associated
> with the proper smmuv3.

Device property "bus" is strictly for specifying into which the bus the
device is to be plugged.  The device's type must match the bus: only a
PCI device can plug into a PCI bus, and so forth.

A PCI device has a PCI address (dev.fn) on the bus it's plugged into.
If that's not the case for a physical smmuv3, we should not make the
virtual smmuv3 a PCI device.

Is there any prior art in QEMU, or is this the first device of this
kind?