From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753393AbcEIWtp (ORCPT ); Mon, 9 May 2016 18:49:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60549 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753249AbcEIWto (ORCPT ); Mon, 9 May 2016 18:49:44 -0400 Date: Mon, 9 May 2016 16:49:36 -0600 From: Alex Williamson To: Eric Auger Cc: eric.auger@st.com, robin.murphy@arm.com, will.deacon@arm.com, joro@8bytes.org, tglx@linutronix.de, jason@lakedaemon.net, marc.zyngier@arm.com, christoffer.dall@linaro.org, linux-arm-kernel@lists.infradead.org, patches@linaro.org, linux-kernel@vger.kernel.org, Bharat.Bhushan@freescale.com, pranav.sawargaonkar@gmail.com, p.fedin@samsung.com, iommu@lists.linux-foundation.org, Jean-Philippe.Brucker@arm.com, julien.grall@arm.com, yehuday@marvell.com Subject: Re: [PATCH v9 3/7] vfio/type1: bypass unmap/unpin and replay for VFIO_IOVA_RESERVED slots Message-ID: <20160509164936.1a5ae402@t450s.home> In-Reply-To: <1462362858-2925-4-git-send-email-eric.auger@linaro.org> References: <1462362858-2925-1-git-send-email-eric.auger@linaro.org> <1462362858-2925-4-git-send-email-eric.auger@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 09 May 2016 22:49:37 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 4 May 2016 11:54:14 +0000 Eric Auger 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, 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, typically the MSI layer which is > responsible to free and unmap them. The MSI mapping resources are freeed > by the IOMMU driver on domain destruction. > > Signed-off-by: Eric Auger > > --- > > v7 -> v8: > - do no destroy anything anymore, just bypass unmap/unpin and iommu_map > on replay > --- > drivers/vfio/vfio_iommu_type1.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c > index 2d769d4..94a9916 100644 > --- a/drivers/vfio/vfio_iommu_type1.c > +++ b/drivers/vfio/vfio_iommu_type1.c > @@ -391,7 +391,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 > @@ -727,6 +727,9 @@ 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) > + continue; > + But you do still need some sort of replay mechanism, right? Not to replay the IOVA to PA mapping, but to call iommu_msi_set_aperture() for the new domain. How will you know that this entry is an MSI reserved range or something else? Perhaps we can't have a generic "reserved" type here. > while (iova < dma->iova + dma->size) { > phys_addr_t phys = iommu_iova_to_phys(d->domain, iova); > size_t size; From mboxrd@z Thu Jan 1 00:00:00 1970 From: alex.williamson@redhat.com (Alex Williamson) Date: Mon, 9 May 2016 16:49:36 -0600 Subject: [PATCH v9 3/7] vfio/type1: bypass unmap/unpin and replay for VFIO_IOVA_RESERVED slots In-Reply-To: <1462362858-2925-4-git-send-email-eric.auger@linaro.org> References: <1462362858-2925-1-git-send-email-eric.auger@linaro.org> <1462362858-2925-4-git-send-email-eric.auger@linaro.org> Message-ID: <20160509164936.1a5ae402@t450s.home> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, 4 May 2016 11:54:14 +0000 Eric Auger 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, 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, typically the MSI layer which is > responsible to free and unmap them. The MSI mapping resources are freeed > by the IOMMU driver on domain destruction. > > Signed-off-by: Eric Auger > > --- > > v7 -> v8: > - do no destroy anything anymore, just bypass unmap/unpin and iommu_map > on replay > --- > drivers/vfio/vfio_iommu_type1.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c > index 2d769d4..94a9916 100644 > --- a/drivers/vfio/vfio_iommu_type1.c > +++ b/drivers/vfio/vfio_iommu_type1.c > @@ -391,7 +391,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 > @@ -727,6 +727,9 @@ 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) > + continue; > + But you do still need some sort of replay mechanism, right? Not to replay the IOVA to PA mapping, but to call iommu_msi_set_aperture() for the new domain. How will you know that this entry is an MSI reserved range or something else? Perhaps we can't have a generic "reserved" type here. > while (iova < dma->iova + dma->size) { > phys_addr_t phys = iommu_iova_to_phys(d->domain, iova); > size_t size;