On Tue, 2015-10-06 at 08:32 +0000, Bhushan Bharat wrote: > > > > -----Original Message----- > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Tuesday, October 06, 2015 4:15 AM > > To: Bhushan Bharat-R65777 <bharat.bhus...@freescale.com> > > Cc: kvm...@lists.cs.columbia.edu; kvm@vger.kernel.org; > > christoffer.d...@linaro.org; eric.au...@linaro.org; pranavku...@linaro.org; > > marc.zyng...@arm.com; will.dea...@arm.com > > Subject: Re: [RFC PATCH 5/6] vfio-pci: Create iommu mapping for msi > > interrupt > > > > On Mon, 2015-10-05 at 07:20 +0000, Bhushan Bharat wrote: > > > > > > > > > > -----Original Message----- > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > > Sent: Saturday, October 03, 2015 4:17 AM > > > > To: Bhushan Bharat-R65777 <bharat.bhus...@freescale.com> > > > > Cc: kvm...@lists.cs.columbia.edu; kvm@vger.kernel.org; > > > > christoffer.d...@linaro.org; eric.au...@linaro.org; > > > > pranavku...@linaro.org; marc.zyng...@arm.com; will.dea...@arm.com > > > > Subject: Re: [RFC PATCH 5/6] vfio-pci: Create iommu mapping for msi > > > > interrupt > > > > > > > > On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote: > > > > > An MSI-address is allocated and programmed in pcie device during > > > > > interrupt configuration. Now for a pass-through device, try to > > > > > create the iommu mapping for this allocted/programmed msi-address. > > > > > If the iommu mapping is created and the msi address programmed in > > > > > the pcie device is different from msi-iova as per iommu > > > > > programming then reconfigure the pci device to use msi-iova as msi > > address. > > > > > > > > > > Signed-off-by: Bharat Bhushan <bharat.bhus...@freescale.com> > > > > > --- > > > > > drivers/vfio/pci/vfio_pci_intrs.c | 36 > > > > > ++++++++++++++++++++++++++++++++++-- > > > > > 1 file changed, 34 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/drivers/vfio/pci/vfio_pci_intrs.c > > > > > b/drivers/vfio/pci/vfio_pci_intrs.c > > > > > index 1f577b4..c9690af 100644 > > > > > --- a/drivers/vfio/pci/vfio_pci_intrs.c > > > > > +++ b/drivers/vfio/pci/vfio_pci_intrs.c > > > > > @@ -312,13 +312,23 @@ static int vfio_msi_set_vector_signal(struct > > > > vfio_pci_device *vdev, > > > > > int irq = msix ? vdev->msix[vector].vector : pdev->irq + vector; > > > > > char *name = msix ? "vfio-msix" : "vfio-msi"; > > > > > struct eventfd_ctx *trigger; > > > > > + struct msi_msg msg; > > > > > + struct vfio_device *device; > > > > > + uint64_t msi_addr, msi_iova; > > > > > int ret; > > > > > > > > > > if (vector >= vdev->num_ctx) > > > > > return -EINVAL; > > > > > > > > > > + device = vfio_device_get_from_dev(&pdev->dev); > > > > > > > > Have you looked at this function? I don't think we want to be doing > > > > that every time we want to poke the interrupt configuration. > > > > > > I am trying to describe what I understood, a device can have many > > interrupts and we should setup iommu only once, when called for the first > > time to enable/setup interrupt. > > > Similarly when disabling the interrupt we should iommu-unmap when > > > called for the last enabled interrupt for that device. Now with this > > > understanding, should I move this map-unmap to separate functions and > > > call them from vfio_msi_set_block() rather than in > > > vfio_msi_set_vector_signal() > > > > Interrupts can be setup and torn down at any time and I don't see how one > > function or the other makes much difference. > > vfio_device_get_from_dev() is enough overhead that the data we need > > should be cached if we're going to call it with some regularity. Maybe > > vfio_iommu_driver_ops.open() should be called with a pointer to the > > vfio_device... or the vfio_group. > > vfio_iommu_driver_ops.open() ? or do you mean vfio_pci_open() should be > called with vfio_device or vfio_group, and we will cache that in > vfio_pci_device ?
vfio_pci_open() is an implementation of vfio_iommu_driver_ops.open(). The internal API between vfio and vfio bus drivers would need to have a parameter added. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
