Donald Dutile <ddut...@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?
