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. 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, -- Peter Xu