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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B6FE7C433F5 for ; Mon, 14 Mar 2022 11:32:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tA7i8mdREbFcvd3XKd18K1LV2n/B58dOijeX+Umx+Co=; b=BDT9W21BL78PrK z3ceIglRj2wra8Np0gfKcHCbkSQIHNCPhmG4lyd69yfgRjqC0AhgmlxcW2T431iyuyrOe0zQ9MbdO PlljgRE1l/UzVQ27ARHPD+beF42GUmXRAR4y/Oh4oyVt8t0aoGhC23J8mVkGxeVa6nypKMOZc9Xnq w/cwbz4K3aErB+UAfIOoyzbcKFJl3n885QBjYcAigY3SGVT1STqDr8GkDAuA6419p7ftTtdUv+aYT LSASPxKPbBt0m2Wl7cpCDMXI0TLD0Je7BessX0DCMlrqDqPn6pgCoyePbGMCASRVd2twGCd7J42fH oNxf8azEcTeyTqSRBi2w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nTiuU-0059Ta-Sc; Mon, 14 Mar 2022 11:30:47 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nTiuQ-0059Sh-Hr for linux-arm-kernel@lists.infradead.org; Mon, 14 Mar 2022 11:30:44 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AC2B9106F; Mon, 14 Mar 2022 04:30:39 -0700 (PDT) Received: from lpieralisi (unknown [10.57.42.155]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 578FF3F99C; Mon, 14 Mar 2022 04:30:37 -0700 (PDT) Date: Mon, 14 Mar 2022 11:30:31 +0000 From: Lorenzo Pieralisi To: Ard Biesheuvel Cc: Eric Auger , Robin Murphy , Shameer Kolothum , Linux ARM , ACPI Devel Maling List , Linux IOMMU , Linuxarm , Joerg Roedel , Will Deacon , wanghuiqiang , Hanjun Guo , Steven Price , Sami Mujawar , Jon Nettleton , yangyicong Subject: Re: [PATCH v8 00/11] ACPI/IORT: Support for IORT RMR node Message-ID: References: <20220221154344.2126-1-shameerali.kolothum.thodi@huawei.com> <8ecce421-e2ee-1a19-ae2d-a8454a8a5844@arm.com> <0cde239c-8d30-33a8-6e5b-792e30e20462@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220314_043042_742013_6F72560E X-CRM114-Status: GOOD ( 39.94 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Mon, Mar 14, 2022 at 11:43:51AM +0100, Ard Biesheuvel wrote: > On Mon, 14 Mar 2022 at 11:37, Eric Auger wrote: > > > > Hi Robin > > > > On 3/11/22 11:34 AM, Robin Murphy wrote: > > > On 2022-03-11 08:19, Eric Auger wrote: > > >> Hi guys, > > >> > > >> On 2/21/22 4:43 PM, Shameer Kolothum wrote: > > >>> Hi, > > >>> > > >>> Since we now have an updated verion[0] of IORT spec(E.d) which > > >>> addresses the memory attributes issues discussed here [1], > > >>> this series now make use of it. > > >>> > > >>> The pull request for ACPICA E.d related changes are already > > >>> raised and can be found here, > > >>> https://github.com/acpica/acpica/pull/752 > > >>> > > >>> v7 --> v8 > > >>> - Patch #1 has temp definitions for RMR related changes till > > >>> the ACPICA header changes are part of kernel. > > >>> - No early parsing of RMR node info and is only parsed at the > > >>> time of use. > > >>> - Changes to the RMR get/put API format compared to the > > >>> previous version. > > >>> - Support for RMR descriptor shared by multiple stream IDs. > > >>> > > >>> Please take a look and let me know your thoughts. > > >>> > > >>> Thanks, > > >>> Shameer > > >>> [0] https://developer.arm.com/documentation/den0049/ed/ > > >> I still have a question on the IORT E.d spec (unrelated to this series). > > >> > > >> The spec mandates that if RMR nodes are presented in the IORT, > > >> _DSM function #5 for the PCIe host bridge ACPI device object must return > > >> 0, indicating the OS must honour the PCI config that the FW computed at > > >> boot time. > > >> > > >> However implementing this _DSM #5 as above is known to prevent PCI > > >> devices with IO ports from working, on aarch64 linux. > > >> > > >> " > > >> The reason is that EFI creates I/O port mappings below > > >> 0x1000 (in fact, at 0). However Linux, for legacy reasons, does not > > >> support I/O ports <= 0x1000 on PCI, so the I/O assignment > > >> created by EFI > > >> is rejected. > > >> EFI creates the mappings primarily for itself, and up until > > >> DSM #5 > > >> started to be enforced, all PCI resource allocations that > > >> existed at > > >> boot were ignored by Linux and recreated from scratch. > > >> " > > >> > > >> This is an excerpt of a qemu commit message that reverted the _DMS #5 > > >> change (Revert "acpi/gpex: Inform os to keep firmware resource map"). > > >> Has the situation changed since July 2021 (ie. has UEFI been reworked?). > > >> [+ Ard] > > > > > > FWIW I wasn't aware of that, but if it's an issue then it will need to > > > be fixed in Linux or UEFI's PCI resource code (arguably if UEFI has > > > already allocated from the bottom of I/O space then Linux should be > > > safe to assume that there are no legacy PC I/O resources to worry > > > about). The DSM is required to prevent bus numbers being reassigned, > > > because if that happens then any PCI StreamIDs referenced in IORT may > > > suddenly become meaningless and the association of root complex nodes > > > and RMRs to physical hardware lost. > > > > Thank you for confirming and explaining the need for DSM #5. Ard, please > > could you confirm that the incompatibility with PCI devices with IO > > ports is still there? > > > > Yes, and this needs to be fixed in Linux. The firmware complies with > the pertinent specifications, and it is Linux that deviates from this > for legacy reasons. > > IIRC, this came up on the mailing list at some point, and one of the > issues is that I/O port 0x0 is mistaken for 'no resource' or some > other exceptional case like that, so even if we fix the arbitrary > limit of 0x1000, we may still run into trouble when devices uses I/O > port 0x0. Yes, I need to go back to that thread to sort this out. Thanks, Lorenzo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel