Re: [Qemu-arm] [Qemu-devel] [RFC v4 00/16] VIRTIO-IOMMU device

[Tian, Kevin]

> From: Auger Eric [mailto:address@hidden
> 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 <address@hidden> wrote:
> >> Hi Peter,
> >>
> >> On 11/10/2017 16:56, Peter Maydell wrote:
> >>> On 19 September 2017 at 08:46, Eric Auger <address@hidden>
> 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