Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757269AbcDGRuM (ORCPT ); Thu, 7 Apr 2016 13:50:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50355 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757177AbcDGRuH (ORCPT ); Thu, 7 Apr 2016 13:50:07 -0400 Date: Thu, 7 Apr 2016 11:50:01 -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, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, suravee.suthikulpanit@amd.com, patches@linaro.org, linux-kernel@vger.kernel.org, Manish.Jaggi@caviumnetworks.com, 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 Subject: Re: [PATCH v6 0/7] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes Message-ID: <20160407115001.25de7d1e@t450s.home> In-Reply-To: <5706528B.2010906@linaro.org> References: <1459757222-2668-1-git-send-email-eric.auger@linaro.org> <20160406171534.794c6824@t450s.home> <5706528B.2010906@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1607 Lines: 36 On Thu, 7 Apr 2016 14:28:59 +0200 Eric Auger wrote: > Hi Alex, > On 04/07/2016 01:15 AM, Alex Williamson wrote: > > On Mon, 4 Apr 2016 08:06:55 +0000 > > Eric Auger 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. 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, Alex