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

[markmi_dsl-only.net]

Summary

I've used this type of variation 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 , 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.

The diff presented is against:

# ~/fbsd-based-on-what-commit.sh -C /usr/main-src/
branch: main
merge-base: 4d1ba6febfa7c7808027fd1ef60b3bffadd17853
merge-base: CommitDate: 2022-03-22 23:58:48 +0000
4d1ba6febfa7 (HEAD -> main, freebsd/main, freebsd/HEAD) bsdinstall hardening: Replace dialog with bsddialog
n253904 (--first-parent --count for merge-base)

Note: I was far from sure that this form of submittal of a variant was reasonable. It is my second ever submittal here. I simply duplicated the Reviewers and Subscribers lists. I've no problem if someone that knows what they are doing for this context wants to just make it more appropriate in any way. My view of things is rather narrow/limited.

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. I do use the patch in all my buildworld's that I install, not just for RPi4B's: ThreadRipper 1950X, HoneyComb, MACCHIATObin Double Shot, Rock64, OrangePi Plus 2ed, RPi3B, RPi2B. But, except for activity that happens to be buildworld or buildkernel, or poudriere bulk activity, my normal use is rather limited testing. I have the patch in my builds for main [so: 14], stable/13 , releng/13.1 , and releng/13.0 .

I'm unsure if there is anything that FreeBSD supports besides a RPi4B B0T stepping that provides a way to have testing potentially fail by needing to use the new code (D25219 overall, not just my specific adjustment).

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, C0T stepping or Rev 1.5 RPi4B's, or so on.