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: [PATCH v13 11/15] vfio/type1: Handle unmap/unpin and replay for VFIO_IOVA_RESERVED slots
Date: Thu, 6 Oct 2016 14:19:18 -0600	[thread overview]
Message-ID: <20161006141918.67928391@t450s.home> (raw)
In-Reply-To: <1475743531-4780-12-git-send-email-eric.auger@redhat.com>

On Thu,  6 Oct 2016 08:45:27 +0000
Eric Auger <eric.auger@redhat.com> wrote:

> Before allowing the end-user to create VFIO_IOVA_RESERVED dma slots,
> let's implement the expected behavior for removal and replay.
> 
> As opposed to user dma slots, reserved IOVAs are not systematically bound
> to PAs and PAs are not pinned. VFIO just initializes the IOVA "aperture".
> IOVAs are allocated outside of the VFIO framework, by the MSI layer which
> is responsible to free and unmap them. The MSI mapping resources are freeed

nit, extra 'e', "freed"

> by the IOMMU driver on domain destruction.
> 
> On the creation of a new domain, the "replay" of a reserved slot simply
> needs to set the MSI aperture on the new domain.
> 
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> 
> ---
> v12 -> v13:
> - use dma-iommu iommu_get_dma_msi_region_cookie
> 
> v9 -> v10:
> - replay of a reserved slot sets the MSI aperture on the new domain
> - use VFIO_IOVA_RESERVED_MSI enum value instead of VFIO_IOVA_RESERVED
> 
> v7 -> v8:
> - do no destroy anything anymore, just bypass unmap/unpin and iommu_map
>   on replay
> ---
>  drivers/vfio/Kconfig            |  1 +
>  drivers/vfio/vfio_iommu_type1.c | 10 +++++++++-
>  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> index da6e2ce..673ec79 100644
> --- a/drivers/vfio/Kconfig
> +++ b/drivers/vfio/Kconfig
> @@ -1,6 +1,7 @@
>  config VFIO_IOMMU_TYPE1
>  	tristate
>  	depends on VFIO
> +	select IOMMU_DMA
>  	default n
>  
>  config VFIO_IOMMU_SPAPR_TCE
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 65a4038..5bc5fc9 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -36,6 +36,7 @@
>  #include <linux/uaccess.h>
>  #include <linux/vfio.h>
>  #include <linux/workqueue.h>
> +#include <linux/dma-iommu.h>
>  
>  #define DRIVER_VERSION  "0.2"
>  #define DRIVER_AUTHOR   "Alex Williamson <alex.williamson@redhat.com>"
> @@ -387,7 +388,7 @@ static void vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma *dma)
>  	struct vfio_domain *domain, *d;
>  	long unlocked = 0;
>  
> -	if (!dma->size)
> +	if (!dma->size || dma->type != VFIO_IOVA_USER)
>  		return;
>  	/*
>  	 * We use the IOMMU to track the physical addresses, otherwise we'd
> @@ -724,6 +725,13 @@ static int vfio_iommu_replay(struct vfio_iommu *iommu,
>  		dma = rb_entry(n, struct vfio_dma, node);
>  		iova = dma->iova;
>  
> +		if (dma->type == VFIO_IOVA_RESERVED_MSI) {
> +			ret = iommu_get_dma_msi_region_cookie(domain->domain,
> +						     dma->iova, dma->size);
> +			WARN_ON(ret);
> +			continue;
> +		}

Why is this a passable error?  We consider an iommu_map() error on any
entry a failure.

> +
>  		while (iova < dma->iova + dma->size) {
>  			phys_addr_t phys = iommu_iova_to_phys(d->domain, iova);
>  			size_t size;

  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 [this message]
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
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=20161006141918.67928391@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).