Re: [Qemu-arm] [Qemu-devel] [PATCH v7 00/20] ARM SMMUv3 Emulation Support

[Linu Cherian]

On Thu Sep 28, 2017 at 09:54:20AM +0200, Auger Eric wrote:
> 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

Thanks for confirming. 

> 
> 
> > 
> > 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,
> > 

-- 
Linu cherian