kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Mon, 05 Oct 2015 16:44:56 -0600	[thread overview]
Message-ID: <1444085096.26107.363.camel@redhat.com> (raw)
In-Reply-To: <CY1PR0301MB1276F1B231284369F36D486490480@CY1PR0301MB1276.namprd03.prod.outlook.com>

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.

> >  Also note that
> > IOMMU mappings don't operate on devices, but groups, so maybe we want
> > to pass the group.
> 
> Yes, it operates on group. I hesitated to add an API to get group. Do you suggest to that it is ok to add API to get group from device.

No, the above suggestion is probably better.

> > 
> > > +	if (device == NULL)
> > > +		return -EINVAL;
> > 
> > This would be a legitimate BUG_ON(!device)
> > 
> > > +
> > >  	if (vdev->ctx[vector].trigger) {
> > >  		free_irq(irq, vdev->ctx[vector].trigger);
> > > +		get_cached_msi_msg(irq, &msg);
> > > +		msi_iova = ((u64)msg.address_hi << 32) | msg.address_lo;
> > > +		vfio_device_unmap_msi(device, msi_iova, PAGE_SIZE);
> > >  		kfree(vdev->ctx[vector].name);
> > >  		eventfd_ctx_put(vdev->ctx[vector].trigger);
> > >  		vdev->ctx[vector].trigger = NULL;
> > > @@ -346,12 +356,11 @@ static int vfio_msi_set_vector_signal(struct
> > vfio_pci_device *vdev,
> > >  	 * cached value of the message prior to enabling.
> > >  	 */
> > >  	if (msix) {
> > > -		struct msi_msg msg;
> > > -
> > >  		get_cached_msi_msg(irq, &msg);
> > >  		pci_write_msi_msg(irq, &msg);
> > >  	}
> > >
> > > +
> > 
> > gratuitous newline
> > 
> > >  	ret = request_irq(irq, vfio_msihandler, 0,
> > >  			  vdev->ctx[vector].name, trigger);
> > >  	if (ret) {
> > > @@ -360,6 +369,29 @@ static int vfio_msi_set_vector_signal(struct
> > vfio_pci_device *vdev,
> > >  		return ret;
> > >  	}
> > >
> > > +	/* Re-program the new-iova in pci-device in case there is
> > > +	 * different iommu-mapping created for programmed msi-address.
> > > +	 */
> > > +	get_cached_msi_msg(irq, &msg);
> > > +	msi_iova = 0;
> > > +	msi_addr = (u64)(msg.address_hi) << 32 | (u64)(msg.address_lo);
> > > +	ret = vfio_device_map_msi(device, msi_addr, PAGE_SIZE,
> > &msi_iova);
> > > +	if (ret) {
> > > +		free_irq(irq, vdev->ctx[vector].trigger);
> > > +		kfree(vdev->ctx[vector].name);
> > > +		eventfd_ctx_put(trigger);
> > > +		return ret;
> > > +	}
> > > +
> > > +	/* Reprogram only if iommu-mapped iova is different from msi-
> > address */
> > > +	if (msi_iova && (msi_iova != msi_addr)) {
> > > +		msg.address_hi = (u32)(msi_iova >> 32);
> > > +		/* Keep Lower bits from original msi message address */
> > > +		msg.address_lo &= PAGE_MASK;
> > > +		msg.address_lo |= (u32)(msi_iova & 0x00000000ffffffff);
> > 
> > Seems like you're making some assumptions here that are dependent on the
> > architecture and maybe the platform.
> 
> What I tried is to map the msi page with different iova, which is page size aligned. But the offset within the page will remain same.
> For example, original msi address was 0x0603_0040 and we have a reserved region at 0xf000_0000. So iommu mapping is created for 0xf000_0000 =>0x0600_3000 of size 0x1000.
> 
> So the new address to be programmed in device is 0xf000_0040, offset 0x40 added to base address in iommu mapping.

Don't you need ~PAGE_MASK for it to work like that?  The & with
0x00000000ffffffff shouldn't be needed either, certainly not with all
the leading zeros.

> > > +		pci_write_msi_msg(irq, &msg);
> > > +	}
> > > +
> > >  	vdev->ctx[vector].trigger = trigger;
> > >
> > >  	return 0;
> > 
> > 
> 




  reply	other threads:[~2015-10-05 22:44 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1443624989-24346-1-git-send-email-Bharat.Bhushan@freescale.com>
2015-09-30 14:56 ` [RFC PATCH 2/6] iommu: Add interface to get msi-pages mapping attributes 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-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-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 11:02   ` kbuild test robot
2015-09-30 11:32     ` Bhushan Bharat
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 [this message]
2015-10-06  8:32         ` Bhushan Bharat
2015-10-06 15:06           ` Alex Williamson
2015-09-30 14:56 ` [RFC PATCH 6/6] arm-smmu: Allow to set iommu mapping for MSI 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=1444085096.26107.363.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).