Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1374238

Re: [PATCH v6 0/7] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes

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

Show all headers | View raw


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 | NextPrevious in thread | Find similar | Unroll thread


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