Page MenuHomeFreeBSD

powerpc64: fix OFWFB with Radix MMU
Needs ReviewPublic

Authored by luporl on Tue, Jul 20, 1:16 PM.

Details

Reviewers
None
Group Reviewers
PowerPC
Summary

Current implementation of Radix MMU doesn't support mapping
arbitrary virtual addresses, such as the ones generated by
"direct mapping" I/O addresses. This caused the system to hang, when
early I/O addresses, such as those used by OpenFirmware Frame Buffer,
were remapped after the MMU was up.

To avoid having to modify mmu_radix_kenter_attr just to support this
use case, this change makes early I/O map use virtual addresses from
KVA area instead (similar to what mmu_radix_mapdev_attr does), as
these can be safely remapped later.

I'm not really sure if this is the best way to fix this, so suggestions with better approaches are welcome!

Test Plan

Tested on a Talos II machine, with built in VGA used through OFWFB.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 40551
Build 37440: arc lint + arc unit

Event Timeline

Great job luporl!

I tested this patch on Raptor Blackbird, as well with D30626 and D30797 (modified version) applied and they all work fine together.

sys/powerpc/aim/aim_machdep.c
594

I'd prefer to have "radix_mmu" available for user tunning independent of ISA version.
And use D30797 to set "radix_mmu=1" if PPC_FEATURE2_ARCH_3_00 bit is set.

sys/powerpc/aim/aim_machdep.c
594

The problem is we can't allow radix_mmu=1 if ARCH is lower than 3.0 (before POWER9).
Radix is not supported on these architectures and there are some parts in trap.c that checks radix_mmu to decide how to handle exceptions.

Also, this is basically what previous code was doing, just on an earlier spot.
D30797 would remain almost the same too. We would just need to set radix_mmu to 1 on initialization or right before fetching the tunable.
Either way, this part that sets radix_mmu to 0 if !ARCH_3_00 would guarantee it to be off when not supported.