Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp354652ybg; Tue, 9 Jun 2020 02:17:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwfybRGvdex4g8bpmVkJ2uG0TSGfc6L9vJr4VLlYFrMB4aDUTlETSutCk11FSBjXY6h79md X-Received: by 2002:a17:906:d9cd:: with SMTP id qk13mr24291924ejb.268.1591694276089; Tue, 09 Jun 2020 02:17:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591694276; cv=none; d=google.com; s=arc-20160816; b=iUTVKV+AV+b2tXnTTQqHqbgiBx7njxLHkprvfSxfYzXxqg7NubGhkMDH6xm1bHu/za fWFkY2hV+oqvcGGvki4F9fzbo9bPDb8Y4GtSdvqEUUaX9Oi0ltNa4Dp1ro1d/ePm6D0R CVP4e9nPuP7hOAuHh7byv0Vu8gBCNWJhQYVdzurfKdbt/RNMNeLMpm25qhYI2YXoPtOO 8+FEn8vbtNrHR3uaCPlrpUSSSpT/fgZWmqvfmZHZWiNcSjkrO0nEKAmrNTn/SIlHM5ZS 1hocRXbNQZGjdF/yLgPBVtCdek5XGQhRfh4JB0afCmJLqpoU2HEI3V8F+IcRK7ixIn0b N0iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=bQ0n5An1Xq95sVxV42yicxBiMjId5rslchbQ4rliio8=; b=v/8irOIMUoVmwE0xsBecrdJSzMZUcZH+y0xO5q+Pr/uDV9TnKgDY7EozRGbH2eocVV fGhO/t3kXlYgZTU9LcaxRyp8dOlt6OdhPG4CJiXVL+aPNg164TmHhb4bLJAnqEjwhkyK /Czzhi53uMQs+fGAa/zXuiVBSKUCWD3nD8eC3/ceh7FmtsAjdNxfTOShA9aD+OuQCJ1B BZ6RVR0J/oAQLzHy6X4carhpKKHQAbr0yYE/3epvzP2A4doAAeTDI7eFgjIkfk079B2J TqqSoPGaFMggRsu7yTNDbabNjtghjPDbxjAa0DYpKcpkkVCdnRvpwErkfJ9mCPXSL4w3 RNRg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l4si10746444edi.316.2020.06.09.02.17.32; Tue, 09 Jun 2020 02:17:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728153AbgFIJPa convert rfc822-to-8bit (ORCPT + 99 others); Tue, 9 Jun 2020 05:15:30 -0400 Received: from mout.kundenserver.de ([217.72.192.75]:55037 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726778AbgFIJP2 (ORCPT ); Tue, 9 Jun 2020 05:15:28 -0400 Received: from mail-qt1-f172.google.com ([209.85.160.172]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.145]) with ESMTPSA (Nemesis) id 1N2m7O-1ixPAe2F7E-0132Hu; Tue, 09 Jun 2020 11:15:24 +0200 Received: by mail-qt1-f172.google.com with SMTP id z1so17033042qtn.2; Tue, 09 Jun 2020 02:15:24 -0700 (PDT) X-Gm-Message-State: AOAM530RS4NuecT0s1oQr4x5f7MC0L6huT56ymvbTGx6JeZJh5qu27pn lQOZlupwS82j3k6qHBlk9tTZB4uQOL4CgcrbNuY= X-Received: by 2002:ac8:4742:: with SMTP id k2mr27989059qtp.304.1591694122865; Tue, 09 Jun 2020 02:15:22 -0700 (PDT) MIME-Version: 1.0 References: <20200608164148.GA1394249@bjorn-Precision-5520> In-Reply-To: From: Arnd Bergmann Date: Tue, 9 Jun 2020 11:15:06 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU To: Zhangfei Gao Cc: Bjorn Helgaas , Joerg Roedel , Bjorn Helgaas , Lorenzo Pieralisi , Hanjun Guo , Sudeep Holla , "Rafael J. Wysocki" , Len Brown , jean-philippe , Greg Kroah-Hartman , Herbert Xu , kenneth-lee-2012@foxmail.com, Wangzhou , "linux-kernel@vger.kernel.org" , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , "open list:IOMMU DRIVERS" , ACPI Devel Maling List , Linux ARM , linux-pci Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Provags-ID: V03:K1:kGYb3jMmETbHk7ETfChJPcg/kM3FCJJZyPXx2XC8g5Ud8G3UIHU xevtugFVfk44vd4itd6CeUSdhZ1TR+dMXfGOdfYN8RFRs0t2r3J7BtVJRhJasrZihguscsm TtxP+C2qRGuRL/nPub9KTWp9a/JVDQqUdXz+RMVjRKDW9tPyM8C55HldJstRePmeIPeHqDO A9fsJQT/cC7nc471uW3jQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:QGEsjw7JNoI=:qdRg51FIcOUv/GbrX7H8NU du6LH6NLpibryVn24IY3CrezHYu8HbUwKgMnamWMKV5Ntqwy148m/mbIv8mUBPRbNlRZHf6sF Qw3tYHvhV25Y99dTHUj1JrGTZj8m/Qh2kVzgMj06tPNJ4mFHKvFxGbEFEKuk/bxKZGQ4JdJzB 6vBGIHT6UvmRqALLZNgfEVvAWcWHuR7fIAwcAkzSqXIPGZQNKhmnMIfltPQ5xbFz+20IMUk7T E25RJNPZ1CO3+1pbZIaN8ZvcjVrjYQti647DdUfsCfboku7bJY4jFVbPD/u4mWquoz3sug7Ve xFWXqGW0EvAYinaE5IdIB7dAn4Wjk3Xo6cZKPq7RPK+2WIsT1QAxQn76hUN1afVjftxFPDXFv OsIveDASndAX/kKKR+nSnCSC8H65BlRrqcvNr700bS7S6wPES0bqO2FP3fVzy0/WZbE0plOE3 pyywpEWtC02Pdnzu3sW/ftCMaHZgDALBYj6fwh4PdwMkKL3qmxtMkJ0OIpC/DsylQQomuHTdy wWgIp9BtzAQwzLAxiXBtXl07VZsjEODDFzxITnAt9JnPXI8ybZQ1GyvoYLB26rE1atxHOZA2z dKIHB5i9IANvwJrgwE79cc6RBdOrvbbzxRw/sPQeZZ96Mr3g3IYnjiWEvZc0eqmKln1wNUKHC dMRIVTtgnsllyrjESTy6ms3bLXh150dpetTWGamRv6aa6xNJEcEPnUlH8OdBk135xA/NKTBju C1VItJ6DSwqiJDIZUO9aDZkY16oRCdMYuoErBv23z1xc0hc9mwICqf6KFawbPVpR98NDybRhF 4aMjJNXE7j11IKWW8KxlBuuqgB8Xba5FMLCd/HPrSUtZy2Sklo= Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Tue, Jun 9, 2020 at 6:02 AM Zhangfei Gao wrote: > On 2020/6/9 上午12:41, Bjorn Helgaas wrote: > > On Mon, Jun 08, 2020 at 10:54:15AM +0800, Zhangfei Gao wrote: > >> On 2020/6/6 上午7:19, Bjorn Helgaas wrote: > >>>> +++ b/drivers/iommu/iommu.c > >>>> @@ -2418,6 +2418,10 @@ int iommu_fwspec_init(struct device *dev, struct > >>>> fwnode_handle *iommu_fwnode, > >>>> fwspec->iommu_fwnode = iommu_fwnode; > >>>> fwspec->ops = ops; > >>>> dev_iommu_fwspec_set(dev, fwspec); > >>>> + > >>>> + if (dev_is_pci(dev)) > >>>> + pci_fixup_device(pci_fixup_final, to_pci_dev(dev)); > >>>> + > >>>> > >>>> Then pci_fixup_final will be called twice, the first in pci_bus_add_device. > >>>> Here in iommu_fwspec_init is the second time, specifically for iommu_fwspec. > >>>> Will send this when 5.8-rc1 is open. > >>> Wait, this whole fixup approach seems wrong to me. No matter how you > >>> do the fixup, it's still a fixup, which means it requires ongoing > >>> maintenance. Surely we don't want to have to add the Vendor/Device ID > >>> for every new AMBA device that comes along, do we? > >>> > >> Here the fake pci device has standard PCI cfg space, but physical > >> implementation is base on AMBA > >> They can provide pasid feature. > >> However, > >> 1, does not support tlp since they are not real pci devices. > >> 2. does not support pri, instead support stall (provided by smmu) > >> And stall is not a pci feature, so it is not described in struct pci_dev, > >> but in struct iommu_fwspec. > >> So we use this fixup to tell pci system that the devices can support stall, > >> and hereby support pasid. > > This did not answer my question. Are you proposing that we update a > > quirk every time a new AMBA device is released? I don't think that > > would be a good model. > > Yes, you are right, but we do not have any better idea yet. > Currently we have three fake pci devices, which support stall and pasid. > We have to let pci system know the device can support pasid, because of > stall feature, though not support pri. > Do you have any other ideas? It sounds like the best way would be to allocate a PCI capability for it, so detection can be done through config space, at least in future devices, or possibly after a firmware update if the config space in your system is controlled by firmware somewhere. Once there is a proper mechanism to do this, using fixups to detect the early devices that don't use that should be uncontroversial. I have no idea what the process or timeline is to add new capabilities into the PCIe specification, or if this one would be acceptable to the PCI SIG at all. If detection cannot be done through PCI config space, the next best alternative is to pass auxiliary data through firmware. On DT based machines, you can list non-hotpluggable PCIe devices and add custom properties that could be read during device enumeration. I assume ACPI has something similar, but I have not done that. Arnd