From: alex.williamson@redhat.com (Alex Williamson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v13 12/15] vfio: Allow reserved msi iova registration
Date: Thu, 6 Oct 2016 14:19:32 -0600 [thread overview]
Message-ID: <20161006141932.0a193f9b@t450s.home> (raw)
In-Reply-To: <1475743531-4780-13-git-send-email-eric.auger@redhat.com>
On Thu, 6 Oct 2016 08:45:28 +0000
Eric Auger <eric.auger@redhat.com> wrote:
> The user is allowed to register a reserved MSI IOVA range by using the
> DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA.
> This region is stored in the vfio_dma rb tree. At that point the iova
> range is not mapped to any target address yet. The host kernel will use
> those iova when needed, typically when MSIs are allocated.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
>
> ---
> v12 -> v13:
> - use iommu_get_dma_msi_region_cookie
>
> v9 -> v10
> - use VFIO_IOVA_RESERVED_MSI enum value
>
> v7 -> v8:
> - use iommu_msi_set_aperture function. There is no notion of
> unregistration anymore since the reserved msi slot remains
> until the container gets closed.
>
> v6 -> v7:
> - use iommu_free_reserved_iova_domain
> - convey prot attributes downto dma-reserved-iommu iova domain creation
> - reserved bindings teardown now performed on iommu domain destruction
> - rename VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA into
> VFIO_DMA_MAP_FLAG_RESERVED_MSI_IOVA
> - change title
> - pass the protection attribute to dma-reserved-iommu API
>
> v3 -> v4:
> - use iommu_alloc/free_reserved_iova_domain exported by dma-reserved-iommu
> - protect vfio_register_reserved_iova_range implementation with
> CONFIG_IOMMU_DMA_RESERVED
> - handle unregistration by user-space and on vfio_iommu_type1 release
>
> v1 -> v2:
> - set returned value according to alloc_reserved_iova_domain result
> - free the iova domains in case any error occurs
>
> RFC v1 -> v1:
> - takes into account Alex comments, based on
> [RFC PATCH 1/6] vfio: Add interface for add/del reserved iova region:
> - use the existing dma map/unmap ioctl interface with a flag to register
> a reserved IOVA range. A single reserved iova region is allowed.
> ---
> drivers/vfio/vfio_iommu_type1.c | 77 ++++++++++++++++++++++++++++++++++++++++-
> include/uapi/linux/vfio.h | 10 +++++-
> 2 files changed, 85 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 5bc5fc9..c2f8bd9 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -442,6 +442,20 @@ static void vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma *dma)
> vfio_lock_acct(-unlocked);
> }
>
> +static int vfio_set_msi_aperture(struct vfio_iommu *iommu,
> + dma_addr_t iova, size_t size)
> +{
> + struct vfio_domain *d;
> + int ret = 0;
> +
> + list_for_each_entry(d, &iommu->domain_list, next) {
> + ret = iommu_get_dma_msi_region_cookie(d->domain, iova, size);
> + if (ret)
> + break;
> + }
> + return ret;
Doesn't this need an unwind on failure loop?
> +}
> +
> static void vfio_remove_dma(struct vfio_iommu *iommu, struct vfio_dma *dma)
> {
> vfio_unmap_unpin(iommu, dma);
> @@ -691,6 +705,63 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,
> return ret;
> }
>
> +static int vfio_register_msi_range(struct vfio_iommu *iommu,
> + struct vfio_iommu_type1_dma_map *map)
> +{
> + dma_addr_t iova = map->iova;
> + size_t size = map->size;
> + int ret = 0;
> + struct vfio_dma *dma;
> + unsigned long order;
> + uint64_t mask;
> +
> + /* Verify that none of our __u64 fields overflow */
> + if (map->size != size || map->iova != iova)
> + return -EINVAL;
> +
> + order = __ffs(vfio_pgsize_bitmap(iommu));
> + mask = ((uint64_t)1 << order) - 1;
> +
> + WARN_ON(mask & PAGE_MASK);
> +
> + if (!size || (size | iova) & mask)
> + return -EINVAL;
> +
> + /* Don't allow IOVA address wrap */
> + if (iova + size - 1 < iova)
> + return -EINVAL;
> +
> + mutex_lock(&iommu->lock);
> +
> + if (vfio_find_dma(iommu, iova, size, VFIO_IOVA_ANY)) {
> + ret = -EEXIST;
> + goto unlock;
> + }
> +
> + dma = kzalloc(sizeof(*dma), GFP_KERNEL);
> + if (!dma) {
> + ret = -ENOMEM;
> + goto unlock;
> + }
> +
> + dma->iova = iova;
> + dma->size = size;
> + dma->type = VFIO_IOVA_RESERVED_MSI;
> +
> + ret = vfio_set_msi_aperture(iommu, iova, size);
> + if (ret)
> + goto free_unlock;
> +
> + vfio_link_dma(iommu, dma);
> + goto unlock;
> +
> +free_unlock:
> + kfree(dma);
> +unlock:
> + mutex_unlock(&iommu->lock);
> + return ret;
> +}
> +
> static int vfio_bus_type(struct device *dev, void *data)
> {
> struct bus_type **bus = data;
> @@ -1064,7 +1135,8 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
> } else if (cmd == VFIO_IOMMU_MAP_DMA) {
> struct vfio_iommu_type1_dma_map map;
> uint32_t mask = VFIO_DMA_MAP_FLAG_READ |
> - VFIO_DMA_MAP_FLAG_WRITE;
> + VFIO_DMA_MAP_FLAG_WRITE |
> + VFIO_DMA_MAP_FLAG_RESERVED_MSI_IOVA;
>
> minsz = offsetofend(struct vfio_iommu_type1_dma_map, size);
>
> @@ -1074,6 +1146,9 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
> if (map.argsz < minsz || map.flags & ~mask)
> return -EINVAL;
>
> + if (map.flags & VFIO_DMA_MAP_FLAG_RESERVED_MSI_IOVA)
> + return vfio_register_msi_range(iommu, &map);
> +
> return vfio_dma_do_map(iommu, &map);
>
> } else if (cmd == VFIO_IOMMU_UNMAP_DMA) {
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 255a211..4a9dbc2 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -498,12 +498,19 @@ struct vfio_iommu_type1_info {
> *
> * Map process virtual addresses to IO virtual addresses using the
> * provided struct vfio_dma_map. Caller sets argsz. READ &/ WRITE required.
> + *
> + * In case RESERVED_MSI_IOVA flag is set, the API only aims at registering an
> + * IOVA region that will be used on some platforms to map the host MSI frames.
> + * In that specific case, vaddr is ignored. Once registered, an MSI reserved
> + * IOVA region stays until the container is closed.
> */
> struct vfio_iommu_type1_dma_map {
> __u32 argsz;
> __u32 flags;
> #define VFIO_DMA_MAP_FLAG_READ (1 << 0) /* readable from device */
> #define VFIO_DMA_MAP_FLAG_WRITE (1 << 1) /* writable from device */
> +/* reserved iova for MSI vectors*/
> +#define VFIO_DMA_MAP_FLAG_RESERVED_MSI_IOVA (1 << 2)
> __u64 vaddr; /* Process virtual address */
> __u64 iova; /* IO virtual address */
> __u64 size; /* Size of mapping (bytes) */
> @@ -519,7 +526,8 @@ struct vfio_iommu_type1_dma_map {
> * Caller sets argsz. The actual unmapped size is returned in the size
> * field. No guarantee is made to the user that arbitrary unmaps of iova
> * or size different from those used in the original mapping call will
> - * succeed.
> + * succeed. Once registered, an MSI region cannot be unmapped and stays
> + * until the container is closed.
> */
> struct vfio_iommu_type1_dma_unmap {
> __u32 argsz;
What happens when an x86 user does a mapping with this new flag set?
It seems like we end up configuring everything just as we would on a
platform requiring MSI mapping, including setting the domain MSI
geometry. Should we be testing the MSI geometry flag on the iommu to
see if this is supported? Surprisingly few things seem to check that
flag.
next prev parent reply other threads:[~2016-10-06 20:19 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-06 8:45 [PATCH v13 00/15] KVM PCIe/MSI passthrough on ARM/ARM64 Eric Auger
2016-10-06 8:45 ` [PATCH v13 01/15] iommu: Introduce DOMAIN_ATTR_MSI_GEOMETRY Eric Auger
2016-10-06 8:45 ` [PATCH v13 02/15] iommu/arm-smmu: Initialize the msi geometry Eric Auger
2016-10-06 20:16 ` Alex Williamson
2016-10-06 8:45 ` [PATCH v13 03/15] iommu/dma: Allow MSI-only cookies Eric Auger
2016-10-06 20:17 ` Alex Williamson
2016-10-07 17:14 ` Auger Eric
2016-10-10 14:26 ` Robin Murphy
2016-10-10 14:47 ` Auger Eric
2016-10-10 15:52 ` Robin Murphy
2016-10-06 8:45 ` [PATCH v13 04/15] genirq/msi: Introduce the MSI doorbell API Eric Auger
2016-10-06 20:17 ` Alex Williamson
2016-10-07 17:13 ` Auger Eric
2016-10-06 8:45 ` [PATCH v13 05/15] genirq/msi: msi_doorbell_calc_pages Eric Auger
2016-10-06 8:45 ` [PATCH v13 06/15] irqchip/gic-v2m: Register the MSI doorbell Eric Auger
2016-10-06 8:45 ` [PATCH v13 07/15] irqchip/gicv3-its: " Eric Auger
2016-10-06 8:45 ` [PATCH v13 08/15] vfio: Introduce a vfio_dma type field Eric Auger
2016-10-06 20:18 ` Alex Williamson
2016-10-06 8:45 ` [PATCH v13 09/15] vfio/type1: vfio_find_dma accepting a type argument Eric Auger
2016-10-06 20:18 ` Alex Williamson
2016-10-06 8:45 ` [PATCH v13 10/15] vfio/type1: Implement recursive vfio_find_dma_from_node Eric Auger
2016-10-06 20:19 ` Alex Williamson
2016-10-06 8:45 ` [PATCH v13 11/15] vfio/type1: Handle unmap/unpin and replay for VFIO_IOVA_RESERVED slots Eric Auger
2016-10-06 20:19 ` Alex Williamson
2016-10-07 17:11 ` Auger Eric
2016-10-06 8:45 ` [PATCH v13 12/15] vfio: Allow reserved msi iova registration Eric Auger
2016-10-06 20:19 ` Alex Williamson [this message]
2016-10-07 17:11 ` Auger Eric
2016-10-07 20:45 ` Alex Williamson
2016-10-06 8:45 ` [PATCH v13 13/15] vfio/type1: Check doorbell safety Eric Auger
2016-10-06 20:19 ` Alex Williamson
2016-10-06 8:45 ` [PATCH v13 14/15] iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP Eric Auger
2016-10-06 8:45 ` [PATCH v13 15/15] vfio/type1: Return the MSI geometry through VFIO_IOMMU_GET_INFO capability chains Eric Auger
2016-10-06 20:20 ` Alex Williamson
2016-10-06 20:42 ` Alex Williamson
2016-10-07 17:10 ` Auger Eric
2016-10-07 20:38 ` Alex Williamson
2016-10-10 15:01 ` Auger Eric
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=20161006141932.0a193f9b@t450s.home \
--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).