ppcmmu: Track translated entries for invalidation - #219
Merged
Merged
Conversation
PAT generation counters make invalidation constant-time by adding a generation check to every TLB lookup, but they added a per-access overhead to compare generation counters. I am swithcing to an alternate approach (explicitly tracking populated entries, which can also be used for BAT-derived entries), and am removing this first to make that diff easier to read. This logically reverts the work from dingusdev#199 (the TLB helper refactoring from dingusdev#203 prevents a mechanical revert).
XNU frequently changes BAT and PAT mappings for physical-memory access. Each resulting context synchronization can walk tens of thousands of TLB entries, which consumes a lot of time. Record the instruction and data TLB slots populated by BAT or PAT and invalidate only those slots. Pending invalidations are coalesced by source, and BAT updates cover PAT-derived entries because a new BAT can shadow a page mapping. Saves another 0.7 secondss in the time it takes to boot Mac OS X 10.3 to the WindowServer (compared to the generational PAT invalidation).
Avoids unncessary TLB invalidations.
mihaip
force-pushed
the
upstream-tlb-flush
branch
from
August 21, 2026 05:47
03b1266 to
c051937
Compare
mihaip
added a commit
to mihaip/dingusppc
that referenced
this pull request
Sep 16, 2026
This fixes booting Mac OS 8.6 hanging at the Happy Mac on the iMac G3. During boot, as part of installing the nanokernel, the OS attempts to do a full TLB flush via a series of `tlbie` instructions. We were trying to respect the effective address that's specified in the instruction, but the semantics of how it should be interpreted are different on the 750 CPU - the [user manual](https://www.nxp.com/docs/en/reference-manual/MPC750UM.pdf) says: > The `tlbie` instruction invalidates all TLB entries indexed by the EA, > and operates on both the instruction and data TLBs simultaneously > invalidating four TLB entries. The index corresponds to bits 14-19 of the EA. We were not respecting the bits 14-19 part (`TLB_VPS_MASK` matched bits 4-19), and thus not matching all expected entries. The stale entries would remain, leading to unexpected behavior. Rather than trying to more precisely model the 750 behavior, we instead flush all PAT-derived TLB entries. This matches QEMU's approach (see qemu/qemu@3dcfb74) and is allowed by [the PowerPC specification](http://refspecs.linux-foundation.org/PPC_hrm.2005mar31.pdf): > For example, the tlbie instruction may be implemented to purge all TLB > entries in a congruence class (that is, all TLB entries indexed by the > specified effective address which can include corresponding entries in > data and instruction TLBs) **or the entire TLB**. As of dingusdev#219 a full flush is not that expensive, thus this does not materially affect performance. The goal of the guest OS is a full TLB flush anyway (hence the sweep of `tlbie` instructions), so we don't end up doing too many extra lookups after they're done. For dingusdev#184
dingusdev
pushed a commit
that referenced
this pull request
Sep 17, 2026
This fixes booting Mac OS 8.6 hanging at the Happy Mac on the iMac G3. During boot, as part of installing the nanokernel, the OS attempts to do a full TLB flush via a series of `tlbie` instructions. We were trying to respect the effective address that's specified in the instruction, but the semantics of how it should be interpreted are different on the 750 CPU - the [user manual](https://www.nxp.com/docs/en/reference-manual/MPC750UM.pdf) says: > The `tlbie` instruction invalidates all TLB entries indexed by the EA, > and operates on both the instruction and data TLBs simultaneously > invalidating four TLB entries. The index corresponds to bits 14-19 of the EA. We were not respecting the bits 14-19 part (`TLB_VPS_MASK` matched bits 4-19), and thus not matching all expected entries. The stale entries would remain, leading to unexpected behavior. Rather than trying to more precisely model the 750 behavior, we instead flush all PAT-derived TLB entries. This matches QEMU's approach (see qemu/qemu@3dcfb74) and is allowed by [the PowerPC specification](http://refspecs.linux-foundation.org/PPC_hrm.2005mar31.pdf): > For example, the tlbie instruction may be implemented to purge all TLB > entries in a congruence class (that is, all TLB entries indexed by the > specified effective address which can include corresponding entries in > data and instruction TLBs) **or the entire TLB**. As of #219 a full flush is not that expensive, thus this does not materially affect performance. The goal of the guest OS is a full TLB flush anyway (hence the sweep of `tlbie` instructions), so we don't end up doing too many extra lookups after they're done. For #184
joevt
pushed a commit
to joevt/dingusppc
that referenced
this pull request
Sep 17, 2026
This fixes booting Mac OS 8.6 hanging at the Happy Mac on the iMac G3. During boot, as part of installing the nanokernel, the OS attempts to do a full TLB flush via a series of `tlbie` instructions. We were trying to respect the effective address that's specified in the instruction, but the semantics of how it should be interpreted are different on the 750 CPU - the [user manual](https://www.nxp.com/docs/en/reference-manual/MPC750UM.pdf) says: > The `tlbie` instruction invalidates all TLB entries indexed by the EA, > and operates on both the instruction and data TLBs simultaneously > invalidating four TLB entries. The index corresponds to bits 14-19 of the EA. We were not respecting the bits 14-19 part (`TLB_VPS_MASK` matched bits 4-19), and thus not matching all expected entries. The stale entries would remain, leading to unexpected behavior. Rather than trying to more precisely model the 750 behavior, we instead flush all PAT-derived TLB entries. This matches QEMU's approach (see qemu/qemu@3dcfb74) and is allowed by [the PowerPC specification](http://refspecs.linux-foundation.org/PPC_hrm.2005mar31.pdf): > For example, the tlbie instruction may be implemented to purge all TLB > entries in a congruence class (that is, all TLB entries indexed by the > specified effective address which can include corresponding entries in > data and instruction TLBs) **or the entire TLB**. As of dingusdev#219 a full flush is not that expensive, thus this does not materially affect performance. The goal of the guest OS is a full TLB flush anyway (hence the sweep of `tlbie` instructions), so we don't end up doing too many extra lookups after they're done. For dingusdev#184
joevt
pushed a commit
to joevt/dingusppc
that referenced
this pull request
Sep 17, 2026
This fixes booting Mac OS 8.6 hanging at the Happy Mac on the iMac G3. During boot, as part of installing the nanokernel, the OS attempts to do a full TLB flush via a series of `tlbie` instructions. We were trying to respect the effective address that's specified in the instruction, but the semantics of how it should be interpreted are different on the 750 CPU - the [user manual](https://www.nxp.com/docs/en/reference-manual/MPC750UM.pdf) says: > The `tlbie` instruction invalidates all TLB entries indexed by the EA, > and operates on both the instruction and data TLBs simultaneously > invalidating four TLB entries. The index corresponds to bits 14-19 of the EA. We were not respecting the bits 14-19 part (`TLB_VPS_MASK` matched bits 4-19), and thus not matching all expected entries. The stale entries would remain, leading to unexpected behavior. Rather than trying to more precisely model the 750 behavior, we instead flush all PAT-derived TLB entries. This matches QEMU's approach (see qemu/qemu@3dcfb74) and is allowed by [the PowerPC specification](http://refspecs.linux-foundation.org/PPC_hrm.2005mar31.pdf): > For example, the tlbie instruction may be implemented to purge all TLB > entries in a congruence class (that is, all TLB entries indexed by the > specified effective address which can include corresponding entries in > data and instruction TLBs) **or the entire TLB**. As of dingusdev#219 a full flush is not that expensive, thus this does not materially affect performance. The goal of the guest OS is a full TLB flush anyway (hence the sweep of `tlbie` instructions), so we don't end up doing too many extra lookups after they're done. For dingusdev#184
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
XNU frequently changes BAT and PAT mappings for physical-memory access. Each resulting context synchronization can walk tens of thousands of TLB entries, which consumes a lot of time.
Record the instruction and data TLB slots populated by BAT or PAT and invalidate only those slots. Pending invalidations are coalesced by source. This supersedes the PAT generational counter optimization from #199 - there are fewer BAT changes after boot, and having the overhead of a generation check on every TLB entry access would have made everything slower.
Also includes an additional optimization skip over no-op BAT writes.
Saves another 0.7 seconds in the time it takes to boot Mac OS X 10.3 to the WindowServer.