From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AAEBCC43334 for ; Fri, 1 Jul 2022 18:19:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:To:Subject:MIME-Version: Date:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=xvb1B4TTAeuLnNmcTfV5SLJrDmIc057guigDoj9QcZs=; b=3bgFwDzv0cB91ofvqbfNl+CBMw PmIWoh72DsQA6Q4rESK86yHUkb3Qme/0yUwMX4jIAGEsKMvpaHCWKiDabV+Su2oRZqaZKWfWTEJ3r 8SbQ0O6hL59Dmm1suv2SU1mrNJJPxCEaX/Jm0xftsLJZNEEtMXgdhGkHwNgdNOyr1tK7nA5rjxN25 eRMYGJyR64beUmGYW0di3gAdLz3+R4W5TVcuUR4+7Gg/66NOuHyr7+M7d8Jc+oo0QVqenkkRq9biS ZCzUZKTn9Y1AnXvfVnGWjPuIyvG7W2ry5GpFWQrGLy9fzGYPr4VjCihJKl61V/R1wuMqiUy7PGOvl Ggsjpclw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o7LDJ-006Lta-M1; Fri, 01 Jul 2022 18:17:57 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o7LDG-006LsC-8H for linux-arm-kernel@lists.infradead.org; Fri, 01 Jul 2022 18:17:55 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A6BA4113E; Fri, 1 Jul 2022 11:17:48 -0700 (PDT) Received: from [10.1.196.40] (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DDCD33F5A1; Fri, 1 Jul 2022 11:17:43 -0700 (PDT) Message-ID: <2ccb6033-4c34-ff59-50a8-549c924d269d@arm.com> Date: Fri, 1 Jul 2022 19:17:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v4 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain and device/group Content-Language: en-GB To: Nicolin Chen References: <20220630203635.33200-1-nicolinc@nvidia.com> <20220630203635.33200-2-nicolinc@nvidia.com> From: Robin Murphy In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220701_111754_411451_4125DDEC X-CRM114-Status: GOOD ( 20.02 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: marcan@marcan.st, mjrosato@linux.ibm.com, linux-kernel@vger.kernel.org, thierry.reding@gmail.com, will@kernel.org, alyssa@rosenzweig.io, jean-philippe@linaro.org, kvm@vger.kernel.org, zhang.lyra@gmail.com, joro@8bytes.org, iommu@lists.linux-foundation.org, jonathanh@nvidia.com, iommu@lists.linux.dev, jgg@nvidia.com, yangyingliang@huawei.com, orsonzhai@gmail.com, gerald.schaefer@linux.ibm.com, kevin.tian@intel.com, sven@svenpeter.dev, linux-arm-msm@vger.kernel.org, john.garry@huawei.com, alex.williamson@redhat.com, christophe.jaillet@wanadoo.fr, thunder.leizhen@huawei.com, linux-tegra@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, chenxiang66@hisilicon.com, linux-s390@vger.kernel.org, cohuck@redhat.com, robdclark@gmail.com, suravee.suthikulpanit@amd.com, baolin.wang7@gmail.com, dwmw2@infradead.org, baolu.lu@linux.intel.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 01/07/2022 5:43 pm, Nicolin Chen wrote: > On Fri, Jul 01, 2022 at 11:21:48AM +0100, Robin Murphy wrote: > >>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c >>> index 2ed3594f384e..072cac5ab5a4 100644 >>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c >>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c >>> @@ -1135,10 +1135,8 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) >>> struct arm_smmu_device *smmu; >>> int ret; >>> >>> - if (!fwspec || fwspec->ops != &arm_smmu_ops) { >>> - dev_err(dev, "cannot attach to SMMU, is it on the same bus?\n"); >>> - return -ENXIO; >>> - } >>> + if (!fwspec || fwspec->ops != &arm_smmu_ops) >>> + return -EMEDIUMTYPE; >> >> This is the wrong check, you want the "if (smmu_domain->smmu != smmu)" >> condition further down. If this one fails it's effectively because the >> device doesn't have an IOMMU at all, and similar to patch #3 it will be > > Thanks for the review! I will fix that. The "on the same bus" is > quite eye-catching. > >> removed once the core code takes over properly (I even have both those >> patches written now!) > > Actually in my v1 the proposal for ops check returned -EMEDIUMTYPE > also upon an ops mismatch, treating that too as an incompatibility. > Do you mean that we should have fine-grained it further? On second look, I think this particular check was already entirely redundant by the time I made the fwspec conversion to it, oh well. Since it remains harmless for the time being, let's just ignore it entirely until we can confidently say goodbye to the whole lot[1]. I don't think there's any need to differentiate an instance mismatch from a driver mismatch, once the latter becomes realistically possible, mostly due to iommu_domain_alloc() also having to become device-aware to know which driver to allocate from. Thus as far as a user is concerned, if attaching a device to an existing domain fails with -EMEDIUMTYPE, allocating a new domain using the given device, and attaching to that, can be expected to succeed, regardless of why the original attempt was rejected. In fact even in the theoretical different-driver-per-bus model the same principle still holds up. Thanks, Robin. [1] https://gitlab.arm.com/linux-arm/linux-rm/-/commit/aa4accfa4a10e92daad0d51095918e8a89014393 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel