On Mon, Mar 14, 2022 at 11:43:51AM +0100, Ard Biesheuvel wrote: > On Mon, 14 Mar 2022 at 11:37, Eric Auger <eric.auger@xxxxxxxxxx> 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
