linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: alex.williamson@redhat.com (Alex Williamson)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 0/2] VFIO: Add virtual MSI doorbell support.
Date: Tue, 28 Jul 2015 10:21:47 -0600	[thread overview]
Message-ID: <1438100507.5211.170.camel@redhat.com> (raw)
In-Reply-To: <1437728590-23126-1-git-send-email-pranavkumar@linaro.org>

On Fri, 2015-07-24 at 14:33 +0530, Pranavkumar Sawargaonkar wrote:
> In current VFIO MSI/MSI-X implementation, linux host kernel
> allocates MSI/MSI-X vectors when userspace requests through vfio ioctls.
> Vfio creates irqfd mappings to notify MSI/MSI-X interrupts
> to the userspace when raised.
> Guest OS will see emulated MSI/MSI-X controller and receives an interrupt
> when kernel notifies the same via irqfd.
> 
> Host kernel allocates MSI/MSI-X using standard linux routines
> like pci_enable_msix_range() and pci_enable_msi_range(). 
> These routines along with requset_irq() in host kernel sets up 
> MSI/MSI-X vectors with Physical MSI/MSI-X addresses provided by
> interrupt controller driver in host kernel.
> 
> This means when a device is assigned with the guest OS, MSI/MSI-X addresses
> present in PCIe EP are the PAs programmed by the host linux kernel.
> 
> In x86 MSI/MSI-X physical address range is reserved and iommu is aware
> about these addreses and transalation is bypassed for these address range.
> 
> Unlike x86, ARM/ARM64 does not reserve MSI/MSI-X Physical address range and
> all the transactions including MSI go through iommu/smmu without bypass.
> This requires extending current vfio MSI layer with additional functionality
> for ARM/ARM64 by
> 1. Programing IOVA (referred as a MSI virtual doorbell address)
>    in device's MSI vector as a MSI address.
>    This IOVA will be provided by the userspace based on the
>    MSI/MSI-X addresses reserved for the guest.
> 2. Create an IOMMU mapping between this IOVA and
>    Physical address (PA) assigned to the MSI vector.
> 
> This RFC is proposing a solution for MSI/MSI-X passthrough for ARM/ARM64.


Hi Pranavkumar,

Freescale has the same, or very similar, need, so any solution in this
space will need to work for both ARM and powerpc.  I'm not a big fan of
this approach as it seems to require the user to configure MSI/X via
ioctl and then call a separate ioctl mapping the doorbells.  That's more
code for the user, more code to get wrong and potentially a gap between
configuring MSI/X and enabling mappings where we could see IOMMU faults.

If we know that doorbell mappings are required, why can't we set aside a
bank of IOVA space and have them mapped automatically as MSI/X is being
configured?  Then the user's need for special knowledge and handling of
this case is limited to setup.  The IOVA space will be mapped and used
as needed, we only need the user to specify the IOVA space reserved for
this.  Thanks,

Alex

  parent reply	other threads:[~2015-07-28 16:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-24  9:03 [RFC 0/2] VFIO: Add virtual MSI doorbell support Pranavkumar Sawargaonkar
2015-07-24  9:03 ` [RFC 1/2] drivers: vfio: iommu map and unmap device specific memory from kernel Pranavkumar Sawargaonkar
2015-07-24  9:03 ` [RFC 2/2] drivers: vfio: pci: Add virtual MSI doorbell support Pranavkumar Sawargaonkar
2015-07-28 16:21 ` Alex Williamson [this message]
2015-07-28 16:55   ` [RFC 0/2] VFIO: " Marc Zyngier
2015-07-28 17:26     ` Alex Williamson
2015-07-28 17:23   ` Bhushan Bharat
2015-07-28 17:58     ` Alex Williamson
2015-08-04  5:48       ` Pranavkumar Sawargaonkar
2015-08-04  5:52         ` Bhushan Bharat
2015-09-22 22:09           ` Marc Zyngier
2015-09-25 17:12             ` Christoffer Dall
2015-09-30  9:37               ` Bhushan Bharat

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=1438100507.5211.170.camel@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).