From: Eric Auger <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Alex Williamson
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: julien.grall-5wv7dgnIgG8@public.gmane.org,
eric.auger-qxv4g6HH51o@public.gmane.org,
jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org,
patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
marc.zyngier-5wv7dgnIgG8@public.gmane.org,
p.fedin-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
yehuday-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org
Subject: Re: [PATCH v9 3/7] vfio/type1: bypass unmap/unpin and replay for VFIO_IOVA_RESERVED slots
Date: Wed, 11 May 2016 14:58:14 +0200 [thread overview]
Message-ID: <57332C66.30105@linaro.org> (raw)
In-Reply-To: <20160509164936.1a5ae402-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org>
Hi Alex,
On 05/10/2016 12:49 AM, Alex Williamson wrote:
> On Wed, 4 May 2016 11:54:14 +0000
> Eric Auger <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 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 <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>
>> ---
>>
>> 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.
Thanks for spotting this bug. I was not testing this case yet and
effectively I need to replay the set_aperture.
Thanks for the review
Best Regards
Eric
>
>> while (iova < dma->iova + dma->size) {
>> phys_addr_t phys = iommu_iova_to_phys(d->domain, iova);
>> size_t size;
>
WARNING: multiple messages have this Message-ID (diff)
From: eric.auger@linaro.org (Eric Auger)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 3/7] vfio/type1: bypass unmap/unpin and replay for VFIO_IOVA_RESERVED slots
Date: Wed, 11 May 2016 14:58:14 +0200 [thread overview]
Message-ID: <57332C66.30105@linaro.org> (raw)
In-Reply-To: <20160509164936.1a5ae402@t450s.home>
Hi Alex,
On 05/10/2016 12:49 AM, Alex Williamson wrote:
> On Wed, 4 May 2016 11:54:14 +0000
> Eric Auger <eric.auger@linaro.org> 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 <eric.auger@linaro.org>
>>
>> ---
>>
>> 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.
Thanks for spotting this bug. I was not testing this case yet and
effectively I need to replay the set_aperture.
Thanks for the review
Best Regards
Eric
>
>> while (iova < dma->iova + dma->size) {
>> phys_addr_t phys = iommu_iova_to_phys(d->domain, iova);
>> size_t size;
>
WARNING: multiple messages have this Message-ID (diff)
From: Eric Auger <eric.auger@linaro.org>
To: Alex Williamson <alex.williamson@redhat.com>
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
Date: Wed, 11 May 2016 14:58:14 +0200 [thread overview]
Message-ID: <57332C66.30105@linaro.org> (raw)
In-Reply-To: <20160509164936.1a5ae402@t450s.home>
Hi Alex,
On 05/10/2016 12:49 AM, Alex Williamson wrote:
> On Wed, 4 May 2016 11:54:14 +0000
> Eric Auger <eric.auger@linaro.org> 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 <eric.auger@linaro.org>
>>
>> ---
>>
>> 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.
Thanks for spotting this bug. I was not testing this case yet and
effectively I need to replay the set_aperture.
Thanks for the review
Best Regards
Eric
>
>> while (iova < dma->iova + dma->size) {
>> phys_addr_t phys = iommu_iova_to_phys(d->domain, iova);
>> size_t size;
>
next prev parent reply other threads:[~2016-05-11 12:58 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-04 11:54 [PATCH v9 0/7] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 3/3: vfio changes Eric Auger
2016-05-04 11:54 ` Eric Auger
2016-05-04 11:54 ` Eric Auger
[not found] ` <1462362858-2925-1-git-send-email-eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-05-04 11:54 ` [PATCH v9 1/7] vfio: introduce a vfio_dma type field Eric Auger
2016-05-04 11:54 ` Eric Auger
2016-05-04 11:54 ` Eric Auger
2016-05-04 11:54 ` [PATCH v9 2/7] vfio/type1: vfio_find_dma accepting a type argument Eric Auger
2016-05-04 11:54 ` Eric Auger
2016-05-04 11:54 ` Eric Auger
[not found] ` <1462362858-2925-3-git-send-email-eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-05-09 22:49 ` Alex Williamson
2016-05-09 22:49 ` Alex Williamson
2016-05-09 22:49 ` Alex Williamson
[not found] ` <20160509164928.518a05a8-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org>
2016-05-10 14:54 ` Eric Auger
2016-05-10 14:54 ` Eric Auger
2016-05-10 14:54 ` Eric Auger
2016-05-04 11:54 ` [PATCH v9 3/7] vfio/type1: bypass unmap/unpin and replay for VFIO_IOVA_RESERVED slots Eric Auger
2016-05-04 11:54 ` Eric Auger
2016-05-04 11:54 ` Eric Auger
2016-05-09 22:49 ` Alex Williamson
2016-05-09 22:49 ` Alex Williamson
[not found] ` <20160509164936.1a5ae402-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org>
2016-05-11 12:58 ` Eric Auger [this message]
2016-05-11 12:58 ` Eric Auger
2016-05-11 12:58 ` Eric Auger
2016-05-04 11:54 ` [PATCH v9 4/7] vfio: allow reserved msi iova registration Eric Auger
2016-05-04 11:54 ` Eric Auger
2016-05-04 11:54 ` Eric Auger
[not found] ` <1462362858-2925-5-git-send-email-eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-05-05 19:22 ` Chalamarla, Tirumalesh
2016-05-05 19:22 ` Chalamarla, Tirumalesh
2016-05-05 19:22 ` Chalamarla, Tirumalesh
[not found] ` <F50F9BB4-1D62-4CAF-BC0E-BE97D222E5A0-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2016-05-09 7:55 ` Eric Auger
2016-05-09 7:55 ` Eric Auger
2016-05-09 7:55 ` Eric Auger
2016-05-10 15:29 ` Alex Williamson
2016-05-10 15:29 ` Alex Williamson
2016-05-10 15:29 ` Alex Williamson
[not found] ` <20160510092951.67c2173e-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org>
2016-05-10 15:34 ` Eric Auger
2016-05-10 15:34 ` Eric Auger
2016-05-10 15:34 ` Eric Auger
2016-05-04 11:54 ` [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at msi domain Eric Auger
2016-05-04 11:54 ` Eric Auger
2016-05-04 11:54 ` Eric Auger
[not found] ` <1462362858-2925-6-git-send-email-eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-05-05 19:23 ` Chalamarla, Tirumalesh
2016-05-05 19:23 ` Chalamarla, Tirumalesh
2016-05-05 19:23 ` Chalamarla, Tirumalesh
[not found] ` <FFD9D7C5-B6EF-4E16-A209-BED31DAB26AA-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2016-05-09 8:05 ` Eric Auger
2016-05-09 8:05 ` Eric Auger
2016-05-09 8:05 ` Eric Auger
2016-05-09 22:49 ` Alex Williamson
2016-05-09 22:49 ` Alex Williamson
2016-05-09 22:49 ` Alex Williamson
[not found] ` <20160509164942.5af8b30d-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org>
2016-05-10 16:10 ` Eric Auger
2016-05-10 16:10 ` Eric Auger
2016-05-10 16:10 ` Eric Auger
[not found] ` <57320803.8070506-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-05-10 17:24 ` Robin Murphy
2016-05-10 17:24 ` Robin Murphy
2016-05-10 17:24 ` Robin Murphy
[not found] ` <57321952.2020206-5wv7dgnIgG8@public.gmane.org>
2016-05-11 8:38 ` Eric Auger
2016-05-11 8:38 ` Eric Auger
2016-05-11 8:38 ` Eric Auger
[not found] ` <5732EF96.4070001-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-05-11 9:31 ` Robin Murphy
2016-05-11 9:31 ` Robin Murphy
2016-05-11 9:31 ` Robin Murphy
[not found] ` <5732FBF0.4040105-5wv7dgnIgG8@public.gmane.org>
2016-05-11 9:44 ` Eric Auger
2016-05-11 9:44 ` Eric Auger
2016-05-11 9:44 ` Eric Auger
[not found] ` <5732FF04.6060202-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-05-11 13:48 ` Robin Murphy
2016-05-11 13:48 ` Robin Murphy
2016-05-11 13:48 ` Robin Murphy
[not found] ` <5733383F.9060202-5wv7dgnIgG8@public.gmane.org>
2016-05-11 14:37 ` Eric Auger
2016-05-11 14:37 ` Eric Auger
2016-05-11 14:37 ` Eric Auger
2016-05-04 11:54 ` [PATCH v9 6/7] iommu/arm-smmu: do not advertise IOMMU_CAP_INTR_REMAP Eric Auger
2016-05-04 11:54 ` Eric Auger
2016-05-04 11:54 ` Eric Auger
2016-05-04 11:54 ` [PATCH v9 7/7] vfio/type1: return MSI geometry through VFIO_IOMMU_GET_INFO capability chains Eric Auger
2016-05-04 11:54 ` Eric Auger
2016-05-04 11:54 ` Eric Auger
[not found] ` <1462362858-2925-8-git-send-email-eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-05-04 12:06 ` Eric Auger
2016-05-04 12:06 ` Eric Auger
2016-05-04 12:06 ` Eric Auger
[not found] ` <5729E5BB.1030101-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-05-09 23:03 ` Alex Williamson
2016-05-09 23:03 ` Alex Williamson
2016-05-09 23:03 ` Alex Williamson
[not found] ` <20160509170312.06e9c4fe-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org>
2016-05-10 16:50 ` Eric Auger
2016-05-10 16:50 ` Eric Auger
2016-05-10 16:50 ` Eric Auger
2016-05-09 22:49 ` Alex Williamson
2016-05-09 22:49 ` Alex Williamson
2016-05-09 22:49 ` Alex Williamson
[not found] ` <20160509164950.0b1cf9c1-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org>
2016-05-10 16:36 ` Eric Auger
2016-05-10 16:36 ` Eric Auger
2016-05-10 16:36 ` Eric Auger
2016-05-20 16:01 ` [PATCH v9 0/7] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 3/3: vfio changes Eric Auger
2016-05-20 16:01 ` Eric Auger
[not found] ` <573F34CA.5080308-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-06-08 8:29 ` Auger Eric
2016-06-08 8:29 ` Auger Eric
2016-06-08 8:29 ` Auger Eric
[not found] ` <875b5791-f7c9-97ca-46de-4b1474fe65e0-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-06-08 21:06 ` Alex Williamson
2016-06-08 21:06 ` Alex Williamson
2016-06-08 21:06 ` Alex Williamson
[not found] ` <20160608150609.7e28d63d-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2016-06-09 7:55 ` Auger Eric
2016-06-09 7:55 ` Auger Eric
2016-06-09 7:55 ` Auger Eric
[not found] ` <e379ffed-6a73-d18a-1af9-a49b096d3f60-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-06-09 19:44 ` Alex Williamson
2016-06-09 19:44 ` Alex Williamson
2016-06-09 19:44 ` Alex Williamson
2016-06-20 15:42 ` Pranav Sawargaonkar
2016-06-20 15:42 ` Pranav Sawargaonkar
2016-06-20 15:46 ` Pranav Sawargaonkar
2016-06-20 15:46 ` Pranav Sawargaonkar
2016-06-20 15:46 ` Pranav Sawargaonkar
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=57332C66.30105@linaro.org \
--to=eric.auger-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
--cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=eric.auger-qxv4g6HH51o@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org \
--cc=julien.grall-5wv7dgnIgG8@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=p.fedin-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
--cc=yehuday-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.