On Thu, 2015-12-03 at 16:16 +0300, Pavel Fedin wrote:
> Hello!
>
> > I like that you're making this transparent
> > for the user, but at the same time, directly calling function pointers
> > through the msi_domain_ops is quite ugly.
>
> Do you mean dereferencing info->ops->vfio_map() in .c code
On Thu, 3 Dec 2015 16:16:54 +0300
Pavel Fedin wrote:
Pavel,
> Hello!
>
> > I like that you're making this transparent
> > for the user, but at the same time, directly calling function pointers
> > through the msi_domain_ops is quite ugly.
>
> Do you mean dereferencing info->ops->vfio_map() i
Hello!
> I like that you're making this transparent
> for the user, but at the same time, directly calling function pointers
> through the msi_domain_ops is quite ugly.
Do you mean dereferencing info->ops->vfio_map() in .c code? I can introduce
some wrappers in include/linux/msi.h like
msi_do
On Tue, 2015-11-24 at 16:50 +0300, Pavel Fedin wrote:
> On some architectures (e.g. ARM64) if the device is behind an IOMMU, and
> is being mapped by VFIO, it is necessary to also add mappings for MSI
> translation register for interrupts to work. This series implements the
> necessary API to do th
On some architectures (e.g. ARM64) if the device is behind an IOMMU, and
is being mapped by VFIO, it is necessary to also add mappings for MSI
translation register for interrupts to work. This series implements the
necessary API to do this, and makes use of this API for GICv3 ITS on
ARM64.
v1 => v