On Wed, 23 Nov 2016 15:53:23 +0800 Jike Song <jike.song@xxxxxxxxx> wrote: > On 11/23/2016 02:33 PM, Tian, Kevin wrote: > >> From: Song, Jike > >> Sent: Wednesday, November 23, 2016 2:30 PM > >> On 11/23/2016 01:56 PM, Alex Williamson wrote: > >>> On Wed, 23 Nov 2016 10:22:37 +0530 > >>> Kirti Wankhede <kwankhede@xxxxxxxxxx> wrote: > >>>> > >>>> Most of the distro's kernel have CONFIG_MODVERSIONS enabled and its > >>>> mostly safe to build driver against the kernel to which its going to load. > >>>> For backend IOMMU module, we have same callback functions or > >>>> VFIO_IOMMU_NOTIFY, but as Alex mentioned different IOMMU backend modules > >>>> might have different events/actions. Then the event check shouldn't be > >>>> in vfio module, it should be in backend module. > >>> > >>> Yes, patch 1/3 is wrong, the required events mask should be passed to > >>> the iommu backend and handled there, not in vfio.c. Thanks, > >> > >> Will change that. BTW, do you think the iommu types should be different? > >> that is to say, having VFIO_IOMMU_NOTIFY_TYPE1 instead of VFIO_IOMMU_NOTIFY? > >> > > > > Should vendor driver care about underlying IOMMU difference? Assume > > those notification events should be IOMMU vendor agnostic... > > I also lean towards keeping VFIO_IOMMU_NOTIFY, will update [1/3] without > changing that part. Agreed, the vendor driver has no visibility to the iommu model selected by the user. The type identifies where the notifier is attached. The event mask allows the vendor driver to set required notifications. If an iommu backend does not support a compatible notification, it doesn't matter whether it's type1 vs spapr vs any future iommu backend type. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
