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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D527EC4361B for ; Wed, 16 Dec 2020 11:26:41 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 63E5922D08 for ; Wed, 16 Dec 2020 11:26:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 63E5922D08 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=hisilicon.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ODarUaKBoaagjFtAWFUAAt8LzXEQgMX6icgXpY8ecSs=; b=GnfhbwDeM0w2ot6M+KLZjn0HD 57EuMvH62xh3silBUfZgTzJGxzrXToU9FcquYl9uN45j71ome/YSFAmF5wkziaTKIVCkbjLXzuIvW iO0ClLtTb5PqTmvhS/2KOps54hd1gSxJjpEDcSkv70nOfbCdC3VCKgWrxkCikNbf7D15NEVShwM01 qCXKWKkGAfax1cjaamreh8kVoDOItccJVxLmsPs1fNCxqoxD7YpeyHtja7pRBXq3Xmcm1mV2t2FvD cc8x9c9LQUPT+n4Exs710jUif/+GIZV6NCEC5ntF1xhG+AW88uaoVfOGUyHNKkBtRUoK9DDEHc7w1 wp+msBvlA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kpUvV-0003TL-CX; Wed, 16 Dec 2020 11:25:01 +0000 Received: from szxga04-in.huawei.com ([45.249.212.190]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kpUvS-0003Rz-5Q for linux-arm-kernel@lists.infradead.org; Wed, 16 Dec 2020 11:24:59 +0000 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4Cwt6t5pxrzkqBb; Wed, 16 Dec 2020 19:23:50 +0800 (CST) Received: from [10.63.139.185] (10.63.139.185) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.498.0; Wed, 16 Dec 2020 19:24:31 +0800 Subject: Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU To: Bjorn Helgaas , Zhangfei Gao References: <20200623150427.GA2403606@bjorn-Precision-5520> From: Zhou Wang Message-ID: <5FD9EE6E.1040505@hisilicon.com> Date: Wed, 16 Dec 2020 19:24:30 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20200623150427.GA2403606@bjorn-Precision-5520> X-Originating-IP: [10.63.139.185] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201216_062458_721586_29919898 X-CRM114-Status: GOOD ( 21.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thanu Rangarajan , jean-philippe , Lorenzo Pieralisi , Souvik Chakravarty , Herbert Xu , Arnd Bergmann , linux-pci , Greg Kroah-Hartman , Joerg Roedel , Hanjun Guo , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , ACPI Devel Maling List , "open list:IOMMU DRIVERS" , wanghuiqiang , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Sudeep Holla , Bjorn Helgaas , kenneth-lee-2012@foxmail.com, Linux ARM , Len Brown Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020/6/23 23:04, Bjorn Helgaas wrote: > On Fri, Jun 19, 2020 at 10:26:54AM +0800, Zhangfei Gao wrote: >> Have studied _DSM method, two issues we met comparing using quirk. >> >> 1. Need change definition of either pci_host_bridge or pci_dev, like adding >> member can_stall, >> while pci system does not know stall now. >> >> a, pci devices do not have uuid: uuid need be described in dsdt, while pci >> devices are not defined in dsdt. >> so we have to use host bridge. > > PCI devices *can* be described in the DSDT. IIUC these particular > devices are hardwired (not plug-in cards), so platform firmware can > know about them and could describe them in the DSDT. > >> b, Parsing dsdt is in in pci subsystem. >> Like drivers/acpi/pci_root.c: >> obj = acpi_evaluate_dsm(ACPI_HANDLE(bus->bridge), &pci_acpi_dsm_guid, >> 1, >> IGNORE_PCI_BOOT_CONFIG_DSM, NULL); >> >> After parsing DSM in pci, we need record this info. >> Currently, can_stall info is recorded in iommu_fwspec, >> which is allocated in iommu_fwspec_init and called by iort_iommu_configure >> for uefi. > > You can look for a _DSM wherever it is convenient for you. It could > be in an AMBA shim layer. > >> 2. Guest kernel also need support sva. >> Using quirk, the guest can boot with sva enabled, since quirk is >> self-contained by kernel. >> If using _DSM, a specific uefi or dtb has to be provided, >> currently we can useQEMU_EFI.fd from apt install qemu-efi > > I don't quite understand what this means, but as I mentioned before, a > quirk for a *limited* number of devices is OK, as long as there is a > plan that removes the need for a quirk for future devices. > > E.g., if the next platform version ships with a DTB or firmware with a > _DSM or other mechanism that enables the kernel to discover this > information without a kernel change, it's fine to use a quirk to cover > the early platform. > > The principles are: > > - I don't want to have to update a quirk for every new Device ID > that needs this. Hi Bjorn and Zhangfei, We plan to use ATS/PRI to support SVA in future PCI devices. However, for current devices, we need to add limited number of quirk to let them work. The device IDs of current quirk needed devices are ZIP engine(0xa250, 0xa251), SEC engine(0xa255, 0xa256), HPRE engine(0xa258, 0xa259), revision id are 0x21 and 0x30. Let's continue to upstream these quirks! Best, Zhou > > - I don't really want to have to manage non-PCI information in the > struct pci_dev. If this is AMBA- or IOMMU-related, it should be > stored in a structure related to AMBA or the IOMMU. > . > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel