Page MenuHomeFreeBSD

arm64/gicv3: Allow us to inherit the LPI mappings
AbandonedPublic

Authored by imp on Jul 7 2023, 12:12 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, May 2, 2:30 PM
Unknown Object (File)
Thu, May 2, 2:30 PM
Unknown Object (File)
Thu, May 2, 11:21 AM
Unknown Object (File)
Fri, Apr 26, 1:05 AM
Unknown Object (File)
Fri, Apr 26, 1:05 AM
Unknown Object (File)
Sun, Apr 21, 2:41 AM
Unknown Object (File)
Thu, Apr 18, 4:52 PM
Unknown Object (File)
Sat, Apr 13, 7:28 AM
Subscribers

Details

Reviewers
andrew
manu
Summary

Due to bugs in the gicv3 hardware, you can't change the LPI
mappings. Add code to read them in if we were booted with LPI enabled
and use those instead of what we would allocate.

Be more pedanic about which bits we trust from region registers.

When forced to reuse an address, make sure its reserved.

Ensure what we do the gicv3 workaround only when it is safe to do
so. Panic if we're forced to re-use an address that wasn't reserved
early in boot. We have no good way if that address was reserved for
this purpose and we won't have two users of that address.

When we're kexec'd from Linux, we have to reuse the memory that was
assigned to the GICv3 ITS since the device can't be disabled enough to
safely change these values without undefined behavior.

Sponsored by: Netflix

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 52468
Build 49359: arc lint + arc unit

Event Timeline

imp requested review of this revision.Jul 7 2023, 12:12 AM

I thought I'd submitted this before, but I don't see where now :(

sys/arm64/arm64/mp_machdep.c
573

This is unrelated, but we need it on our high core count machine.
Maybe we should do something similar to x86?

https://reviews.freebsd.org/D44038 and prior reviews replace this.... at least I hope so.. it doesn't have the mileage this one has, but should be cleaner.