On Mon, Mar 14, 2022 at 11:43:51AM +0100, Ard Biesheuvel wrote:

On Mon, 14 Mar 2022 at 11:37, Eric Auger [off-list ref] wrote:

quoted

Hi Robin

On 3/11/22 11:34 AM, Robin Murphy wrote:

quoted

On 2022-03-11 08:19, Eric Auger wrote:

quoted

Hi guys,

On 2/21/22 4:43 PM, Shameer Kolothum wrote:

quoted

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