On Tue, Oct 24, 2017 at 11:08:02AM +0530, Linu Cherian wrote: > 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 > > > > 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. > > > > Best Regards > > > > Eric > > > > Was looking at options to get rid of the existing hacks we have > in this implementation (last two patches) and also to reduce the > map/unmap/translation > overhead for the guest kernel devices. > > Interestingly, the nested stage translation + smmu emulation at kernel > that we were exploring, has been already tried by Will Deacon. > https://www.linuxplumbersconf.org/2014/ocw/system/presentations/2019/original/vsmmu-lpc14.pdf > https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg03379.html > > > It would be nice to understand, why this solution was not pursued atleast for > vfio-pci devices. > OR > If you have already plans to do nested stage support in the future, would be > interested to know > about it.
I don't plan to revive that code. I got something well on the way to working for SMMUv2, but it had some pretty major issues: 1. A huge amount of emulation code in the kernel 2. A horribly complicated user ABI 3. Keeping track of internal hardware caching state was a nightmare, so over-invalidation was rife 4. Errata workarounds meant trapping all SMMU accesses (inc. for stage 1) 5. I remember having issues with interrupts, but this was likely SMMUv2-specific 6. There was no scope for code re-use with other SMMU implementations (e.g. SMMUv3) Overall, it was just an unmaintainable, non-performant security-flaw-waiting-to-happen so I parked it. That's some of the background behind me preferring a virtio-iommu approach, because there's the potential for kernel acceleration using something like vhost. Will
