From: Alex Williamson <alex.williamson@redhat.com>
To: Bhushan Bharat <Bharat.Bhushan@freescale.com>
Cc: "kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"christoffer.dall@linaro.org" <christoffer.dall@linaro.org>,
"eric.auger@linaro.org" <eric.auger@linaro.org>,
"pranavkumar@linaro.org" <pranavkumar@linaro.org>,
"marc.zyngier@arm.com" <marc.zyngier@arm.com>,
"will.deacon@arm.com" <will.deacon@arm.com>
Subject: Re: [RFC PATCH 5/6] vfio-pci: Create iommu mapping for msi interrupt
Date: Tue, 06 Oct 2015 09:06:37 -0600 [thread overview]
Message-ID: <1444143997.4059.31.camel@redhat.com> (raw)
In-Reply-To: <CY1PR0301MB1276D7FC6ED3D31CF341790490370@CY1PR0301MB1276.namprd03.prod.outlook.com>
On Tue, 2015-10-06 at 08:32 +0000, Bhushan Bharat wrote:
>
>
> > -----Original Message-----
> > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > Sent: Tuesday, October 06, 2015 4:15 AM
> > To: Bhushan Bharat-R65777 <Bharat.Bhushan@freescale.com>
> > Cc: kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org;
> > christoffer.dall@linaro.org; eric.auger@linaro.org; pranavkumar@linaro.org;
> > marc.zyngier@arm.com; will.deacon@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.williamson@redhat.com]
> > > > Sent: Saturday, October 03, 2015 4:17 AM
> > > > To: Bhushan Bharat-R65777 <Bharat.Bhushan@freescale.com>
> > > > Cc: kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org;
> > > > christoffer.dall@linaro.org; eric.auger@linaro.org;
> > > > pranavkumar@linaro.org; marc.zyngier@arm.com; will.deacon@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.Bhushan@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.
next prev parent reply other threads:[~2015-10-06 15:06 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 14:56 [RFC PATCH 1/6] vfio: Add interface for add/del reserved iova region Bharat Bhushan
2015-09-30 14:56 ` [RFC PATCH 2/6] iommu: Add interface to get msi-pages mapping attributes Bharat Bhushan
2015-09-30 14:56 ` Bharat Bhushan
2015-10-02 22:45 ` Alex Williamson
2015-10-05 5:17 ` Bhushan Bharat
2015-10-05 5:56 ` Bhushan Bharat
2015-09-30 14:56 ` [RFC PATCH 3/6] vfio: Extend iommu-info to return MSIs automap state Bharat Bhushan
2015-09-30 14:56 ` Bharat Bhushan
2015-10-02 22:46 ` Alex Williamson
2015-10-05 6:00 ` Bhushan Bharat
2015-10-05 22:45 ` Alex Williamson
2015-10-06 8:53 ` Bhushan Bharat
2015-10-06 15:11 ` Alex Williamson
2015-09-30 14:56 ` [RFC PATCH 4/6] vfio: Add interface to iommu-map/unmap MSI pages Bharat Bhushan
2015-09-30 14:56 ` Bharat Bhushan
2015-10-02 22:46 ` Alex Williamson
2015-10-05 6:27 ` Bhushan Bharat
2015-10-05 22:45 ` Alex Williamson
2015-10-06 9:05 ` Bhushan Bharat
2015-10-06 15:12 ` Alex Williamson
2015-09-30 14:56 ` [RFC PATCH 5/6] vfio-pci: Create iommu mapping for msi interrupt Bharat Bhushan
2015-09-30 14:56 ` Bharat Bhushan
2015-09-30 11:02 ` kbuild test robot
2015-09-30 11:02 ` kbuild test robot
2015-09-30 11:32 ` Bhushan Bharat
2015-09-30 11:34 ` kbuild test robot
2015-09-30 11:34 ` kbuild test robot
2015-10-02 22:46 ` Alex Williamson
2015-10-05 7:20 ` Bhushan Bharat
2015-10-05 22:44 ` Alex Williamson
2015-10-06 8:32 ` Bhushan Bharat
2015-10-06 15:06 ` Alex Williamson [this message]
2015-09-30 14:56 ` [RFC PATCH 6/6] arm-smmu: Allow to set iommu mapping for MSI Bharat Bhushan
2015-09-30 14:56 ` Bharat Bhushan
2015-10-02 22:46 ` Alex Williamson
2015-10-05 8:33 ` Bhushan Bharat
2015-10-05 22:54 ` Alex Williamson
2015-10-06 10:26 ` Bhushan Bharat
2015-10-26 15:40 ` Christoffer Dall
2015-11-02 2:53 ` Pranavkumar Sawargaonkar
2015-10-02 22:45 ` [RFC PATCH 1/6] vfio: Add interface for add/del reserved iova region Alex Williamson
2015-10-05 4:55 ` Bhushan Bharat
2015-10-05 22:45 ` Alex Williamson
2015-10-06 9:39 ` Bhushan Bharat
2015-10-06 15:21 ` Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1444143997.4059.31.camel@redhat.com \
--to=alex.williamson@redhat.com \
--cc=Bharat.Bhushan@freescale.com \
--cc=christoffer.dall@linaro.org \
--cc=eric.auger@linaro.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=marc.zyngier@arm.com \
--cc=pranavkumar@linaro.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.