From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Date: Fri, 08 Jul 2022 13:59:28 +0000 Subject: Re: [PATCH kernel] powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains Message-Id: <20220708135928.GA64621@nvidia.com> List-Id: References: <20220707135552.3688927-1-aik@ozlabs.ru> <20220707151002.GB1705032@nvidia.com> <20220708115522.GD1705032@nvidia.com> <20220708131910.GA3744@nvidia.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexey Kardashevskiy Cc: linuxppc-dev@lists.ozlabs.org, Robin Murphy , Michael Ellerman , Joerg Roedel , Joel Stanley , Alex Williamson , Oliver O'Halloran , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, Daniel Henrique Barboza , Fabiano Rosas , Murilo Opsfelder Araujo , Nicholas Piggin On Fri, Jul 08, 2022 at 11:32:58PM +1000, Alexey Kardashevskiy wrote: > > For power the default domain should be NULL > > > > NULL means that the platform is using the group to provide its DMA > > ops. IIRC this patch was already setup correctly to do this? > > > > The transition from NULL to blocking must isolate the group so all DMA > > is blocked. blocking to NULL should re-estbalish platform DMA API > > control. > > > > The default domain should be non-NULL when the normal dma-iommu stuff is > > providing the DMA API. > > > > So, I think it is already setup properly, it is just the question of > > what to do when entering/leaving blocking mode. > > Well, the patch calls iommu_probe_device() which calls > iommu_alloc_default_domain() which creates IOMMU_DOMAIN_BLOCKED > (=0) as Yes, we always create a blocking domain during probe, but it isn't used until required > nothing initialized iommu_def_domain_type. Need a different default type > (and return NULL when IOMMU API tries creating this type)? iommu_alloc_default_domain() should fail on power because none of the domain types it tries to create are supported. This should result in a NULL group->default_domain Jason