Re: [Qemu-devel] [RFC v1 7/7] vhost: abort if an emulated iommu is used

[Alex Williamson <alex.williamson@redhat.com>]

On Thu, 2012-10-11 at 17:48 +0200, Avi Kivity wrote:
> On 10/11/2012 05:34 PM, Michael S. Tsirkin wrote:
> > On Thu, Oct 11, 2012 at 04:35:23PM +0200, Avi Kivity wrote:
> >> On 10/11/2012 04:35 PM, Michael S. Tsirkin wrote:
> >> 
> >> >> No, qemu should configure virtio devices to bypass the iommu, even if it
> >> >> is on.
> >> > 
> >> > Okay so there will be some API that virtio devices should call
> >> > to achieve this?
> >> 
> >> The iommu should probably call pci_device_bypasses_iommu() to check for
> >> such devices.
> > 
> > So maybe this patch should depend on the introduction of such
> > an API.
> 
> I've dropped it for now.
> 
> In fact, virtio/vhost are safe since they use cpu_physical_memory_rw()
> and the memory listener watches address_space_memory, no iommu there.
> vfio needs to change to listen to pci_dev->bus_master_as, and need
> special handling for iommu regions (abort for now, type 2 iommu later).

I don't see how we can ever support an assigned device with the
translate function.  Don't we want a flat address space at run time
anyway?  IOMMU drivers go to pains to make IOTLB updates efficient and
drivers optimize for long running translations, but here we impose a
penalty on every access.  I think we'd be more efficient and better able
to support assigned devices if the per device/bus address space was
updated and flattened when it changes.  Being able to implement an XOR
IOMMU is impressive, but is it practical?  We could be doing much more
practical things like nested device assignment with a flatten
translation ;)  Thanks,

Alex