Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp201288ybg; Mon, 8 Jun 2020 21:03:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJybX7g4AsW+DvoUx5otd9G83K3DpBRURJJ3oTxQnRqsn8EoJ0jIUTdYHtm6InY8LGKJ66bD X-Received: by 2002:a50:fb0b:: with SMTP id d11mr25600565edq.118.1591675386827; Mon, 08 Jun 2020 21:03:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591675386; cv=none; d=google.com; s=arc-20160816; b=KQyqdoeY5q5iNnMylcv0zARvMOGu9tjNeVneQPDlK8dAtZ0ik3SHK8mIQw+O/lTi+v 6+KZeu8kr2XSUHNY60R3W+tlhMyxZ6c7X+3btmbTPgPGzkndJPkdv9/AP8JCLJZiBl48 BFqPqDnto+K8zr5Aj7YbkCyMcLP7bNc4kEd3tBiSuyC2rscHuWmliFfAKDuVYxZwVt/2 S7JojtHgsGAP3ip8qpbFbkeIEOLSV252LDoLNC8hgvXowfKZTLVBW2h/jrveK2Q6NyLb JkDGHsHflU94HjdG2SUh1t396OkeGGsno1D24e4+zkBFeOGUxLZwPwoR5zTmWBwUCaNY 66jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=HNzwmKC7EPXO6n3v52ZypjHWMqVja532n8n2Tl/XPzU=; b=fObjJ0KE+ZdyCOAOBvvKIUwVRbAgKWGQjaJynDDb9jY3O2V0RyUbvtnZj6dQG8GcOw DOZp1d8/nxP73IQ6q7GVos0PrxKbJR0QDQczDRuBRdUt+3QSTc2WfNkSki2VVWQORS61 5RI/S4+TRnVh3IUatMnaR8m5RiQwGRzcmm1b0AK8hWOekzophlSrrDOWKLfAoj9tpcOE oaaSrAMrRJ/utO+9k2p+CFridnZ3yUK87CIj9JRGXTay2M1SV+0iqdSfT8jDk/lOBtz/ 6yWLOob3u7FuF6OYRwbiK0rYOd9jzT2LNkMmJH7EN2Ln9TZzrI6xWTHGjCEgy2P0OO8W F9sA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=EOIGmeR3; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p9si10390534ejl.1.2020.06.08.21.02.29; Mon, 08 Jun 2020 21:03:06 -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; dkim=pass header.i=@linaro.org header.s=google header.b=EOIGmeR3; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727018AbgFIECR (ORCPT + 99 others); Tue, 9 Jun 2020 00:02:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726286AbgFIECL (ORCPT ); Tue, 9 Jun 2020 00:02:11 -0400 Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4341AC03E97C for ; Mon, 8 Jun 2020 21:02:11 -0700 (PDT) Received: by mail-pl1-x641.google.com with SMTP id n9so7520746plk.1 for ; Mon, 08 Jun 2020 21:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=HNzwmKC7EPXO6n3v52ZypjHWMqVja532n8n2Tl/XPzU=; b=EOIGmeR3il5DVPJCDg4teJziBsjPIErqvQL1NApVhk0fIsJZDquLbvnv9AzOPFDTyM 0Td9tgAsoePC+8tWwHQb/vU9PYB6G/Oyp14FK2hqZEG9usC/15NBI+bjl7shOVkS9PTS doO5YZ3ay6n1fRr9qSicgDl1sKMnJOAKnbUGeudLGxamrgFpyJqMg7/hVpo77ptwayW9 gKyrCeWWc3sisMbmchG7OqNyEieqbYZexGGErCFQFvIiSgU0duds+YBbyLJBINOegnCw yZ0gUZKM/VpvoDsNXIFSXtVpSlXS2LMjFDE0fUXYn6WfLpaSP3YHgKbbD3TgUmNi7e1F Z0fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=HNzwmKC7EPXO6n3v52ZypjHWMqVja532n8n2Tl/XPzU=; b=bUBavx7KQL9y+tKwxrkJAG5v5+K7P8kMV2s+fNVKA+mu/bdjkBKJ8zIDGw9vNIGTaa FWxWkxRTvDfrdrBkvCiz/2NFg8SarVrnNOhyRYF6gmDSgs8JdZnWSplo7HHIGeVGv+fk fEEMeT+bKP6PF+Bn9EVXAULmV9aGZpDVPwJOR8dLl5VwecYh/sjCKD7dYAtmSxiXG/0I oSj9IRyFKbGdxHjNyz2uKoo52DAhu2lRYdQOSQ7Yp04+bMMbHMFoD65Vw1nim9kawlKW rjoas4JJmPIY8+Un3iij20cMU7wvZd3fLbRSydVKKogpx8uJE/eAhpSX2O3xoGIbUsfO Awvg== X-Gm-Message-State: AOAM530e1HF6s7GTdMyLOmnUZ0NUvyXcK04Ku+NIYLD1AfCJl3cndcsx 0nLx+juAI082QA92D/QbClr+4Q== X-Received: by 2002:a17:90a:36cf:: with SMTP id t73mr2680766pjb.100.1591675330529; Mon, 08 Jun 2020 21:02:10 -0700 (PDT) Received: from [10.175.1.166] ([45.135.186.20]) by smtp.gmail.com with ESMTPSA id b24sm8402002pfo.112.2020.06.08.21.02.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 21:02:09 -0700 (PDT) Subject: Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU To: Bjorn Helgaas Cc: Joerg Roedel , Bjorn Helgaas , Arnd Bergmann , 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, linux-crypto@vger.kernel.org, iommu@lists.linux-foundation.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org References: <20200608164148.GA1394249@bjorn-Precision-5520> From: Zhangfei Gao Message-ID: Date: Tue, 9 Jun 2020 12:01:56 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200608164148.GA1394249@bjorn-Precision-5520> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Hi, Bjorn 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: >>> On Thu, Jun 04, 2020 at 09:33:07PM +0800, Zhangfei Gao wrote: >>>> On 2020/6/2 上午1:41, Bjorn Helgaas wrote: >>>>> On Thu, May 28, 2020 at 09:33:44AM +0200, Joerg Roedel wrote: >>>>>> On Wed, May 27, 2020 at 01:18:42PM -0500, Bjorn Helgaas wrote: >>>>>>> Is this slowdown significant? We already iterate over every device >>>>>>> when applying PCI_FIXUP_FINAL quirks, so if we used the existing >>>>>>> PCI_FIXUP_FINAL, we wouldn't be adding a new loop. We would only be >>>>>>> adding two more iterations to the loop in pci_do_fixups() that tries >>>>>>> to match quirks against the current device. I doubt that would be a >>>>>>> measurable slowdown. >>>>>> I don't know how significant it is, but I remember people complaining >>>>>> about adding new PCI quirks because it takes too long for them to run >>>>>> them all. That was in the discussion about the quirk disabling ATS on >>>>>> AMD Stoney systems. >>>>>> >>>>>> So it probably depends on how many PCI devices are in the system whether >>>>>> it causes any measureable slowdown. >>>>> I found this [1] from Paul Menzel, which was a slowdown caused by >>>>> quirk_usb_early_handoff(). I think the real problem is individual >>>>> quirks that take a long time. >>>>> >>>>> The PCI_FIXUP_IOMMU things we're talking about should be fast, and of >>>>> course, they're only run for matching devices anyway. So I'd rather >>>>> keep them as PCI_FIXUP_FINAL than add a whole new phase. >>>>> >>>> Thanks Bjorn for taking time for this. >>>> If so, it would be much simpler. >>>> >>>> +++ 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? Thanks