From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by mx.groups.io with SMTP id smtpd.web11.9213.1608216199360669900 for ; Thu, 17 Dec 2020 06:43:19 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: huawei.com, ip: 185.176.79.56, mailfrom: jonathan.cameron@huawei.com) Received: from fraeml734-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CxZQB4L49z67Q4w; Thu, 17 Dec 2020 22:39:30 +0800 (CST) Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by fraeml734-chm.china.huawei.com (10.206.15.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 17 Dec 2020 15:43:15 +0100 Received: from localhost (10.47.65.229) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 17 Dec 2020 14:43:14 +0000 Date: Thu, 17 Dec 2020 14:42:45 +0000 From: "Jonathan Cameron" To: Ard Biesheuvel CC: , Laszlo Ersek , Jiahui Cen , "Ni, Ray" , "Justen, Jordan L" , "leif@nuviainc.com" , "xieyingtai@huawei.com" , "miaoyubo@huawei.com" , "xuxiaoyang2@huawei.com" , Alex Williamson Subject: Re: [edk2-devel] [PATCH v2 0/4] Add extra pci roots support for Arm Message-ID: <20201217144245.000031d7@Huawei.com> In-Reply-To: References: <20201109130511.5946-1-cenjiahui@huawei.com> <5d2daf54-a57b-c4bd-a757-cf6b710cd4e5@huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; i686-w64-mingw32) MIME-Version: 1.0 X-Originating-IP: [10.47.65.229] X-ClientProxiedBy: lhreml754-chm.china.huawei.com (10.201.108.204) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit On Thu, 17 Dec 2020 14:37:30 +0100 Ard Biesheuvel wrote: > On 12/17/20 2:23 PM, Laszlo Ersek wrote: > > On 12/15/20 13:52, Jiahui Cen wrote: > >> For x86, Linux does not handle the pci resource assignment. But for arm, it > >> would assign all the pci resources, unless we explicitly let Linux preserve > >> PCI resource alignment made by firmware, using "PCI Boot Configuration" > >> _DSM function. > > > > This difference between x86 and arm seems inexplicable to me. > > > >> What do you think of adding "PCI Boot Configuration" _DSM function into > >> dsdt table to make kernel use firmware's resource configuration? > > > > The relevant kernel commits seem to be: > > > > - 18e94a338436 ("PCI: Make a shareable UUID for PCI firmware ACPI _DSM", > > 2015-04-08) > > > > - a78cf9657ba5 ("PCI/ACPI: Evaluate PCI Boot Configuration _DSM", > > 2019-06-21) > > > > I've also read now section "4.6.5. _DSM for Ignoring PCI Boot > > Configurations" in the "PCI(TM) Firmware Specification, > > Revision 3.1, December 13, 2010". > > > > Basically if this _DSM#5 function exists, it tells the OS whether it is > > required to honor the firmware-assigned resources (value 0), or if it is > > free to reassign (value 1). If the function does not exist at all, then, > > "the operating system may continue to use the legacy handling regarding > > the boot configuration". > > > > Without knowing more, I consider it a bug that aarch64 Linux uses a > > default strategy (in the absence of the _DSM#5 function) that is the > > opposite of the x86 default. But, you seem to be right that there is a > > specified way to convince arm64 Linux otherwise. Can you indeed add this > > _DSM#5 function to the "virt" machine's ACPI generator, returning value > > 0, and see if it makes a difference? > > > > That is not going to work, unfortunately. We had a very long discussion > in the PCI SIG firmware subteam about this, and some changes were made > IIRC, but the code does not exist yet in Linux. > > For historical reason, Linux/arm64 always reassigns PCI bus and memory > resources: the ARM port on which arm64 is based does not assume the > existence of any firmware, let only a PCI BIOS that carries out all > those things. When ACPI boot on Linux/arm64 came about, this nuance got > missed, and so even though the presence of rich firmware can obviously > be relied upon in this case, the PCI layer still reassigns some of the > resources in many cases. Note that Linux/x86 might do the same, but is > less likely to do so for modern systems. (My personal favorite is the > Linux/x86 quirk that bases this decision on the BIOS year from DMI) > > One thing that does seem to help on AArch64 is to ensure that the bus > padding is the same for hotplug capable root ports, because this is the > most common reason for reassigning bus numbers. Hi Ard, For an unrelated reason I've been trying to create a setup where bus numbers get reassigned on aarch64 and been unable to do so. I'm looking at potential issues around Generic initiators being defined via BDF and whether we can cache the firmware configured BDF before re enumerating. All sorts of fun happens if the initial setup is not correct (many of which result in unusable systems) but for a 'valid' setup I have not managed to create a case where BDFs move. I can't find a route to reassignment of bus numbers after the _DSM is evaluated (and host->preserve_config is first used). https://elixir.bootlin.com/linux/latest/source/arch/arm64/kernel/pci.c#L194 The padding for bus numbers on root ports seems to be limited to the available space. Note I'm doing messing around in qemu but have edk2 using PciHotplugInit from OVMF to allow straight forward root port padding for hp in edk2. Any pointers would be great! Jonathan > > HTH, > Ard. > > > > > > >