Hi Linu, Peter, On 28/09/2017 09:13, Peter Xu wrote: > On Thu, Sep 28, 2017 at 12:13:12PM +0530, Linu Cherian wrote: >> Hi Eric, >> >> >> On Fri Sep 01, 2017 at 07:21:03PM +0200, Eric Auger wrote: >>> This series implements the emulation code for ARM SMMUv3. >>> >>> Changes since v6: >>> - DPDK testpmd now running on guest with 2 assigned VFs >>> - Changed the instantiation method: add the following option to >>> the QEMU command line >>> -device smmuv3 # for virtio/vhost use cases >>> -device smmuv3,caching-mode # for vfio use cases (based on [1]) >>> - splitted the series into smaller patches to allow the review >>> - the VFIO integration based on "tlbi-on-map" smmuv3 driver >>> is isolated from the rest: last 2 patches, not for upstream. >>> This is shipped for testing/bench until a better solution is found. >>> - Reworked permission flag checks and event generation >>> e testing: >>> - in dt and ACPI modes >>> - virtio-net-pci and vhost-net devices using dma ops with various >>> guest page sizes [2] >>> - assigned VFs using dma ops [3]: >>> - AMD Overdrive and igbvf passthrough (using gsi direct mapping) >>> - Cavium ThunderX and ixgbevf passthrough (using KVM MSI routing) >>> - DPDK testpmd on guest running with VFIO user space drivers (2 igbvf) [3] >>> with guest and host page size equal (4kB) >>> >>> Known limitations: >>> - no VMSAv8-32 suport >>> - no nested stage support (S1 + S2) >>> - no support for HYP mappings >>> - register fine emulation, commands, interrupts and errors were >>> not accurately tested. Handling is sufficient to run use cases >>> described above though. >>> - interrupts and event generation not observed yet. >> >> While testing with vfio-pci, observed that the below two Qemu command, >> results in two different behaviour. Is this expected by design ? >> >> Case 1: >> # -device vfio-pci,host=0002:01:00.3 -device smmuv3,caching-mode >> Here iommu is not attached to the pci bus in Qemu backend, since >> pci_setup_iommu is not called before vfio_realize. >> >> Case 2: >> # -device smmuv3,caching-mode -device vfio-pci,host=0002:01:00.3 >> This works as expected, iommu is attached to the pci bus. > > Not sure about SMMU, but VT-d should have similar issue - the vIOMMU > device needs to be created before the rest of the devices.
Yes this is an expected limitation right now. I should have documented it though. As you noticed, the pci_set_iommu() is called on virtio-iommu realize and it relies on the fact the PCIe devices already are realized. Maybe we could relax this constraint by calling the pci_set_iommu in a machine init done notifier. Thanks Eric > > Now for VT-d the ordering of devices should be assured by Libvirt: > > https://bugzilla.redhat.com/show_bug.cgi?id=1427005 > > For your reference only. Thanks, >
