[RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP

On Fri, Jun 27 2014 at 10:57:28 PM, "Chalamarla, Tirumalesh" [off-list ref] wrote:

Marc,

         What is your opinion on ITS emulation . is it should be part
         of KVM or VFIO.

Making any sort of emulation part of VFIO sounds quite wrong. That's not
what VFIO is about, at all. Emulation belongs to the hypervisor, and
nowhere else.

        Also this code needs to depend on ITS host driver a lot, Host
        ITS driver needs to have an interface for this code to use.

You can share the command interface as some form of library, but that's
about it. There is no more relationship between the ITS driver and the
ITS emulation as there is between the GIC driver and its emulation
counterpart.

	M.

Thanks,
 Tirumalesh
     
-----Original Message-----
From: Will Deacon [mailto:will.deacon at arm.com] 
Sent: Friday, June 27, 2014 1:47 AM
To: Alex Williamson
Cc: Chalamarla, Tirumalesh; Joerg Roedel; kvm at vger.kernel.org; open list; stuart.yoder at freescale.com; iommu at lists.linux-foundation.org; tech at virtualopensystems.com; kvmarm at lists.cs.columbia.edu; moderated list:ARM SMMU DRIVER; marc.zyngier at arm.com
Subject: Re: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP

On Thu, Jun 26, 2014 at 08:36:24PM +0100, Alex Williamson wrote:

quoted

On Thu, 2014-06-26 at 19:10 +0000, Chalamarla, Tirumalesh wrote:

quoted

Thanks for the clarification Alex, That?s exactly my point, why are 
we relying on  QEMU or something else to emulate the MSI space when 
we can directly give access to devices using ITS (of course with a 
small emulation code).  This way we are also benefited from all ITS 
services like VCPU migration etc.

I have no idea what ITS is.

ITS is the MSI doorbell for GICv3 (ARM's latest interrupt controller).

I agree that we will need an ITS emulation if we want to use MSIs in

quoted

the guest, and I believe that Marc (CC'd) had already started
thinking about that.

quoted

quoted

What about non QEMU VFIO users, for example, if I wanted to use VFIO to
assign a device to a user process I don't need to depend on QEMU.   I
thought this is one of the main goals of vfio to make it independent of
hypervisors.     

Where did QEMU become a requirement?  Maybe I'm missing something in 
the ARM part of the conversation that got chopped off, but this is 
exactly why we have the VFIO/QEMU split that we do.  VFIO provides 
basic virtualization for config space and restricts access to other 
areas that users shouldn't be allowed to change.  QEMU is just one 
example of a userspace VFIO driver.  QEMU takes the decomposed device 
exposed through the VFIO ABI and re-creates a PCI device out of it.  
VFIO itself has no dependency on QEMU.  Thanks,

I also don't understand the QEMU part here. The MSI emulation would be

quoted

in the kernel, just like the GICv2 emulation that we already
have. For userspace drivers, wouldn't you just use eventfd rather
than bother with emulating MSIs?

Finally, the interrupt remapping part is about the SMMU preventing MSI

quoted

writes to arbitrary portions of the host address space. The ITS is
about routing interrupts to CPUs.

Will

-- 
Jazz is not dead. It just smells funny.