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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 03FB1CCA47E for ; Wed, 22 Jun 2022 07:55:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352819AbiFVHzD (ORCPT ); Wed, 22 Jun 2022 03:55:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55926 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350096AbiFVHy6 (ORCPT ); Wed, 22 Jun 2022 03:54:58 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0FB9B34666; Wed, 22 Jun 2022 00:54:56 -0700 (PDT) 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 AC87913D5; Wed, 22 Jun 2022 00:54:56 -0700 (PDT) Received: from [10.57.85.1] (unknown [10.57.85.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2E50B3F66F; Wed, 22 Jun 2022 00:54:50 -0700 (PDT) Message-ID: <6e1280c5-4b22-ebb3-3912-6c72bc169982@arm.com> Date: Wed, 22 Jun 2022 08:54:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH v2 3/5] vfio/iommu_type1: Remove the domain->ops comparison Content-Language: en-GB To: Nicolin Chen , "Tian, Kevin" Cc: "joro@8bytes.org" , "will@kernel.org" , "marcan@marcan.st" , "sven@svenpeter.dev" , "robdclark@gmail.com" , "baolu.lu@linux.intel.com" , "matthias.bgg@gmail.com" , "orsonzhai@gmail.com" , "baolin.wang7@gmail.com" , "zhang.lyra@gmail.com" , "jean-philippe@linaro.org" , "alex.williamson@redhat.com" , "jgg@nvidia.com" , "suravee.suthikulpanit@amd.com" , "alyssa@rosenzweig.io" , "dwmw2@infradead.org" , "yong.wu@mediatek.com" , "mjrosato@linux.ibm.com" , "gerald.schaefer@linux.ibm.com" , "thierry.reding@gmail.com" , "vdumpa@nvidia.com" , "jonathanh@nvidia.com" , "cohuck@redhat.com" , "thunder.leizhen@huawei.com" , "tglx@linutronix.de" , "christophe.jaillet@wanadoo.fr" , "john.garry@huawei.com" , "chenxiang66@hisilicon.com" , "saiprakash.ranjan@codeaurora.org" , "isaacm@codeaurora.org" , "yangyingliang@huawei.com" , "jordan@cosmicpenguin.net" , "iommu@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-arm-msm@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , "linux-s390@vger.kernel.org" , "linux-tegra@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "kvm@vger.kernel.org" References: <20220616000304.23890-1-nicolinc@nvidia.com> <20220616000304.23890-4-nicolinc@nvidia.com> From: Robin Murphy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 2022-06-16 23:23, Nicolin Chen wrote: > On Thu, Jun 16, 2022 at 06:40:14AM +0000, Tian, Kevin wrote: > >>> The domain->ops validation was added, as a precaution, for mixed-driver >>> systems. However, at this moment only one iommu driver is possible. So >>> remove it. >> >> It's true on a physical platform. But I'm not sure whether a virtual platform >> is allowed to include multiple e.g. one virtio-iommu alongside a virtual VT-d >> or a virtual smmu. It might be clearer to claim that (as Robin pointed out) >> there is plenty more significant problems than this to solve instead of simply >> saying that only one iommu driver is possible if we don't have explicit code >> to reject such configuration. 😊 > > Will edit this part. Thanks! Oh, physical platforms with mixed IOMMUs definitely exist already. The main point is that while bus_set_iommu still exists, the core code effectively *does* prevent multiple drivers from registering - even in emulated cases like the example above, virtio-iommu and VT-d would both try to bus_set_iommu(&pci_bus_type), and one of them will lose. The aspect which might warrant clarification is that there's no combination of supported drivers which claim non-overlapping buses *and* could appear in the same system - even if you tried to contrive something by emulating, say, VT-d (PCI) alongside rockchip-iommu (platform), you could still only describe one or the other due to ACPI vs. Devicetree. Thanks, Robin.