> From: Auger Eric [mailto:eric.au...@redhat.com] > Sent: Thursday, October 12, 2017 6:10 PM > > Hi Peter, > > On 12/10/2017 11:54, Peter Maydell wrote: > > On 11 October 2017 at 17:08, Auger Eric <eric.au...@redhat.com> wrote: > >> Hi Peter, > >> > >> On 11/10/2017 16:56, Peter Maydell wrote: > >>> On 19 September 2017 at 08:46, Eric Auger <eric.au...@redhat.com> > wrote: > >>>> This series implements the virtio-iommu device. > >>>> > >>>> This v4 is an upgrade to v0.4 spec [1] and applies on QEMU v2.10.0. > >>>> - probe request support although no reserved region is returned at > >>>> the moment > >>>> - unmap semantics less strict, as specified in v0.4 > >>>> - device registration, attach/detach revisited > >>>> - split into smaller patches to ease review > >>>> - propose a way to inform the IOMMU mr about the page_size_mask > >>>> of underlying HW IOMMU, if any > >>>> - remove warning associated with the translation of the MSI doorbell > >>>> > >>>> The device gets instantiated using the "-device virtio-iommu-device" > >>>> option. It currently works with ARM virt machine only, as the machine > >>>> must handle the dt binding between the virtio-mmio "iommu" node > and > >>>> the PCI host bridge node. > >>> > >>> Could this work on x86, or is it inherently arm-only? > >> > >> Yes this is the goal. At the moment the ACPI probing is not yet properly > >> specified but a Q35 prototype was developed in the Red Hat Virt team. > >> This will be presented at the KVM forum. > > > > Since I have very little familiarity with virtio or iommu code, > > I'd be much happier if this was reviewed as a generic virtio-iommu > > by the x86/virtio devs and then the arm specific parts done second... > > Understood. I was rather expecting you to review the smmuv3 emulation > code which you did, in a comprehensive manner ;-), and many thanks for > that. > > Note sure this is time yet to get this RFC reviewed as > - the v0.4 virtio-iommu driver it relies on was not officially submitted, > - the virtio-iommu specification review has not really been reviewed, > - the ACPI probing method has not been discussed yet. > > Jean-Philippe, please correct me if I am wrong. > > So to me, this is pure RFC at the moment. > > > > I'm also not clear on what we're expecting the recommended or normal > > way to do device passthrough is going to be -- this virtio-mmio, > > or presenting the guest with an SMMUv3 interface? Do we really > > need to implement both ? > > I think the KVM forum is the right place to sync as both approaches will > be presented and some pros/cons + performance figures will be given. > > As we talk about choosing, there is one alternative that was suggested > on the ML by Alex & Michael but never really get considered yet and > maybe should be: using intel iommu emulation code for ARM. I > aknowledge > this deserves a thorough impact study on kernel and FW side but I would > be happy to get your opinion about the QEMU side. Would you have a by- > principle rejection of this idea to instantiate such an Intel device in > mach virt or would it be something you would be ready to consider? >
bear posting a link to Alex/Michael's comment? interesting to know the rationale... Thanks Kevin
