qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Xu
Subject: Re: [Qemu-devel] [Qemu-arm] [PATCH v7 00/20] ARM SMMUv3 Emulation Support
Date: Thu, 28 Sep 2017 15:13:59 +0800
User-agent: Mutt/1.5.24 (2015-08-30)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]