Alternative to D25219: ACPI: add support for (inherited) _DMA limits

[markmi_dsl-only.net]

Summary

I've used earlier variations of D25219 for my occasional UEFI/ACPI RPi4B activity since my comments on D25219 not passing my large-file-copy-and-diff testing on RPi4B's with the B0T stepping, Rev 1.4, and >= 4 GiBytes of RAM while using https://github.com/pftf/RPi4 (EDK2 RPi4B UEFI/ACPI testing), tracking as I've updated FreeBSD. The intent vs. D25219 is to, for example, change 0xc0000000 for hw.busdma.zone0.lowaddr to the value shown in:

# sysctl hw.busdma.zone0.lowaddr
hw.busdma.zone0.lowaddr: 0xbfffffff

That matches the kind of values that I've seen in other contexts for hw.busdma.zoneN.lowaddr values. See my notes in D25219 and comments in the submitted code.

# ~/fbsd-based-on-what-commit.sh -C /usr/main-src/
f83db6441a2f (HEAD -> main, freebsd/main, freebsd/HEAD) sctp: minor changes due to upstreaming of Glebs recent changes
branch: main
merge-base: f83db6441a2f4f925a169c7ddf844589cb73c9b5
merge-base: CommitDate: 2022-11-06 22:06:40 +0000
n259064 (--first-parent --count for merge-base)

Test Plan

Beyond creating, say, huge tar files ( such as of /usr/ports/ ) on RPi4B's, duplicating them, and diff'ing the two copies and some normal-operation without noticing problems: good question. The modern cylinder related validations in UFS do make the failures of the existing FreeBSD code on 8 GiByte RPi4B's quickly obvious, unlike when I originally submitted material for this. I do boot a HoneyComb and a MACCHIATObin Double Shot that are ACPI based but do not have such odd DMA limitations.

Note: On RPi4B's with < 4 GiBytes of RAM, or EDK2 configured to limit themselves to 3 GiBytes, I've never seen problems, patched or not. Only 4 GiByte and 8 GiByte ones showed the problem, with or without D25219's patch. No other kind of system ever showed the problem in any configuration. I've never had access to Pi400's or such. I do now have access to one "C0T" RPi4B 8 GiByte.

I does turn out that the existing RPi4B EDK2 UEFI/ACPI (1.33) imposes the 3 GiByte DMA limit for XHCI use, even for "C0T" RPi4B's that do not need the limit. The EDK2 implementation has it hand coded to enforce that limit (or less) in its _DMA information and does not adjust. This somewhat constrains what testing RPi4B's can get.

[markmi_dsl-only.net]

In exploring testing a "C0T" RPi4B 8 GiByte (no odd DMA address limits) and retesting the old "B0T" one (has odd DMA address limits), I've learned that the maximum-address view is directly available via what ACPI's _DMA provides. I've updated the code and the comments for such. This is a recent change, not one that I've used for long at this point. (The prior coding has been in sustained use for a ZFS bectl context but was poorer based on what I now understand.)

The diff is against the vintage of main sources that I happen to have around. I could also produce such for the vintage of stable/13 that I have around. (Prior notes that I'd patched more than main were mistaken: a different type of code had been patched. But now I've patched and done some testing of stable/13 for ACPI.)

It is still very much a variant of D25219. I'm not the original, overall author. I'm just an explorer of variations.