From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966475AbbJ3ONv (ORCPT ); Fri, 30 Oct 2015 10:13:51 -0400 Received: from 8bytes.org ([81.169.241.247]:41765 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966004AbbJ3ONs (ORCPT ); Fri, 30 Oct 2015 10:13:48 -0400 Date: Fri, 30 Oct 2015 15:13:47 +0100 From: Joerg Roedel To: Will Deacon Cc: iommu@lists.linux-foundation.org, Alex Williamson , linux-kernel@vger.kernel.org, Joerg Roedel Subject: Re: [PATCH 8/8] iommu: Move default domain allocation to iommu_group_get_for_dev() Message-ID: <20151030141347.GK27420@8bytes.org> References: <1445464303-18206-1-git-send-email-joro@8bytes.org> <1445464303-18206-9-git-send-email-joro@8bytes.org> <20151029182248.GI3440@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151029182248.GI3440@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Will, On Thu, Oct 29, 2015 at 06:22:49PM +0000, Will Deacon wrote: > The call to iommu_group_get_for_dev in arm_smmu_add_device will end up > calling __iommu_attach_device, since group->domain will now be initialised > by the code above. This means the SMMU driver will see an ->attach_dev > call for a device that is part-way through an ->add_device callback and > will be missing the initialisation necessary for us to idenfity the SMMU > instance to which is corresponds. In fact, the iommudata for the group > won't be initialised at all, so the whole thing will fail afaict. > > Note that I haven't actually taken this for a spin, so I could be missing > something. Yeah, I havn't looked at how to convert the ARM-SMMU drivers to default domains yet, so the issue you describe above is totally possible. But there is no way to trigger it yet, because your domain_alloc function can not yet allocate IOMMU_DOMAIN_DMA domains. While converting the issue must be fixed, of course. I tested this patch-set on an AMD Seattle system and it worked fine there. Joerg