Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1374238
| From | Eric Auger <eric.auger@linaro.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v6 0/7] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes |
| Date | 2016-04-08 15:40 +0200 |
| Message-ID | <rlENH-4tw-7@gated-at.bofh.it> (permalink) |
| References | <rk7Ka-as-9@gated-at.bofh.it> <rl4TT-2ZV-9@gated-at.bofh.it> <rlho6-3Mb-29@gated-at.bofh.it> <rlmnN-7Av-17@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi Alex, On 04/07/2016 07:50 PM, Alex Williamson wrote: > On Thu, 7 Apr 2016 14:28:59 +0200 > Eric Auger <eric.auger@linaro.org> wrote: > >> Hi Alex, >> On 04/07/2016 01:15 AM, Alex Williamson wrote: >>> On Mon, 4 Apr 2016 08:06:55 +0000 >>> Eric Auger <eric.auger@linaro.org> wrote: >>> >>>> This series introduces the dma-reserved-iommu api used to: >>>> - create/destroy an iova domain dedicated to reserved iova bindings >>>> - map/unmap physical addresses onto reserved IOVAs. >>>> - unmap and destroy all IOVA reserved bindings >>> >>> Why are we making the decision to have an unbalanced map vs unmap, we >>> can create individual mappings, but only unmap the whole thing and >>> start over? That's a strange interface. Thanks, >> The "individual" balanced unmap also exists (iommu_put_reserved_iova) >> and this is the "normal" path. This happens on msi_domain_deactivate >> (and possibly on msi_domain_set_affinity). >> >> I added iommu_unmap_reserved to handle the case where the userspace >> registers a reserved iova domain and fails to unregister it. In that >> case one need to handle the cleanup on kernel-side and I chose to >> implement this on vfio_iommu_type1 release. All the reserved IOMMU >> bindings get destroyed on that event. >> >> Any advice to handle this situation? > > If we want to model it similar to regular iommu domains, then > iommu_free_reserved_iova_domain() should release all the mappings and > destroy the iova domain. Yes this sounds obvious now. Additionally, since the reserved iova domain > is just a construct on top of an iommu domain, it should be sufficient > to call iommu_domain_free() to also remove the reserved iova domain if > one exists. Thanks, Yes. For dma cookie (iommu_put_dma_cookie) I see this is done from the iommu driver domain_free callback. Thanks Eric > > Alex >
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH v6 0/7] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes Eric Auger <eric.auger@linaro.org> - 2016-04-04 10:20 +0200
Re: [PATCH v6 0/7] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes Alex Williamson <alex.williamson@redhat.com> - 2016-04-07 01:20 +0200
Re: [PATCH v6 0/7] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes Eric Auger <eric.auger@linaro.org> - 2016-04-07 14:40 +0200
Re: [PATCH v6 0/7] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes Alex Williamson <alex.williamson@redhat.com> - 2016-04-07 20:00 +0200
Re: [PATCH v6 0/7] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes Eric Auger <eric.auger@linaro.org> - 2016-04-08 15:40 +0200
csiph-web