Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp4049280ybg; Sun, 7 Jun 2020 19:55:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyQHoo7atvqQNwG6odM1i/OB/Yl1ysIM0+gg+9cN+woJVWSNbODNx2zXsfQc48ppwAJOubY X-Received: by 2002:a17:906:1d52:: with SMTP id o18mr17689966ejh.399.1591584949119; Sun, 07 Jun 2020 19:55:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591584949; cv=none; d=google.com; s=arc-20160816; b=Q/xt8lDFwcvF4Fe4eOt7+FVWAUakwImbR4BLLmny9O8emf1vqSICTqgiyjQO2yOrqO u4HD4Q/rmVygnaTCSL4yxEjnAcbTqJ6LP94tZEGyNtATMtP6pd/7P2s5I0R+Kisjsj3s 8yZRBXPOmp7dj0hqSiH8Bt6YZ61rzerPpdz6d3ikUdicRmli5xwcHOiXM7Tev7XinQEn gpi4ZumXoGq0Vw3/G15EKMHK8VzWXoy6CMrBFZfBfQ1mYQRuqzQwvJ8hE/qtZYfwPXSj SNpGiDsv+qufjerIiUSonfUnwJF4KBrM3dcY1G85fM6m0l0ObK6SCdrNGYmXnNoi6ShY vFHw== 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=TNiiby0GhibJHmG02ytGWtb3GrXv/h2IE3SFE6qK8wY=; b=LuCkXchR6waU7z06fkSti1kVQTSPFfDGdOA6xC4umQtskGpOalCePZ6+oGGOJhH09y PgI3++pO+x5/ULEMdlE68pUDq4yq0GThPzvTUAFp9HmTSF2wZYL/Kg6mtk/1+niWWIp2 0h4wTTvRq+gr3vN/MWhYSLbK5Zvmv35qhIvECwBoLZq6ceOJVBnc4E/8JmxgDgeRCwpG yh7vV0A02udwS5bF1+nUF0S+goW2pbqu+OJz6Q1JKBIr6/2RpBAOCUavvrwz2FWHb+OV bNUWfPceBQ2IjQP896Wmnts2ch8gN/BNCAwoYR3A8f4GYGgPsM3Zvu+4OOml2dyL3gy3 dyAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=izDTLbNF; 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 oy12si7925531ejb.654.2020.06.07.19.55.12; Sun, 07 Jun 2020 19:55:49 -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=izDTLbNF; 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 S1728916AbgFHCyd (ORCPT + 99 others); Sun, 7 Jun 2020 22:54:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728065AbgFHCya (ORCPT ); Sun, 7 Jun 2020 22:54:30 -0400 Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77FFEC08C5C3 for ; Sun, 7 Jun 2020 19:54:30 -0700 (PDT) Received: by mail-pj1-x1044.google.com with SMTP id ne5so2672852pjb.5 for ; Sun, 07 Jun 2020 19:54:30 -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=TNiiby0GhibJHmG02ytGWtb3GrXv/h2IE3SFE6qK8wY=; b=izDTLbNFapAPFawYa8bP5L1UpCxlkSTCCzx2ye/9STM1DqXymdysNnGkX12FV0/OIo tKcjXEIEuxSNO572pWS545T9DoQqGqTM8DmMcj/pjObZb/s4KuucXPV8lxnGJsPOEWOP creFxg4Q8lnO5UPN6FiY9AkscKdJteM1nKY+Qmci5RctGzZp1Lm8RhpxAeqkzQiUCQxI Gn/htYffz0hnLWeWv7zjKwwzU0TiNbE2IVaAoUldJmQdAcEGN9qicP3+rskQKiUOfzQ9 T1+IF9bYkLx6QP/gZ6BWN651hoOpft0Cc6Lq2cjMJoEoVussc3m5Gv9e47HSM5NkG+Yl PSSg== 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=TNiiby0GhibJHmG02ytGWtb3GrXv/h2IE3SFE6qK8wY=; b=ZoQlRBcjiiRY0gk86AASDBMIwDEQTNTL7ldmT49HjxoW/hKuX6jfbd8I/HKS8PSPq0 ZAl17Hn9k1RuAvLzgjG0UCTSviqZYhoIsJqPX8ESGE7KtZp83kLAzzHRlBJmfCY8DZUR E1XEFvpgbdnSA0IHUW6zAVOp8DwuMQLtGp6foOOLkRVLXKg1rpFnT47Jhs94Bmne8KCl c9DaFQltAVY5WZCyKxH/3QrR0Z6kaScxb2d4TNUqNAKlaHOM0hEoeGd0NsfXakIDVA2M 2BeczfWBDeczgkTSjj0Q4rbOoXX/Oq+lPsr3bxJxP2sQFer00MwxVeVrC3+S/EpRZX+Y ktSg== X-Gm-Message-State: AOAM5302dgUmmo9p2Y5S5QdcP3ndY+McMtL/DVrgOVZmFW+YrELv5b43 uAl31gj7YGIjYO6tBPQ7TmSGrA== X-Received: by 2002:a17:90a:f3c4:: with SMTP id ha4mr15260604pjb.18.1591584870012; Sun, 07 Jun 2020 19:54:30 -0700 (PDT) Received: from [10.80.2.98] ([45.135.186.73]) by smtp.gmail.com with ESMTPSA id t9sm9533489pjs.16.2020.06.07.19.54.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 19:54:29 -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: <20200605231909.GA1155454@bjorn-Precision-5520> From: Zhangfei Gao Message-ID: Date: Mon, 8 Jun 2020 10:54:15 +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: <20200605231909.GA1155454@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/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. Thanks