If an exception occurs while a page-table walk is coincidentally in
progress (e.g., an illegal instruction executes during data TLB refill),
then the processor might enter M-mode. However, the PTW's accesses
should proceed without M privilege, to avoid bypassing PMPs.
Note, the same argument doesn't apply to the nonblocking cache's replay
queues, because those accesses have already been checked against the PMPs.
The cache correctly ignores access exceptions reported on replays,
provided no exceptions were reported on the initial access.
This one's a little invasive. To flush a specific entry from the TLB, you
need to reuse its CAM port. Since the TLB lookup can be on the critical
path, we wish to avoid muxing in another address.
This is simple on the data side, where the datapath already carries rs1 to
the TLB (it's the same path as the AMO address calculation). It's trickier
for the I$, where the TLB lookup address comes from the fetch stage PC.
The trick is to temporarily redirect the PC to rs1, then redirect the PC
again to the instruction after SFENCE.VMA.
Superpages create the possibility that two entries in the TLB may match.
This corresponds to a software bug, but we can't return complete garbage;
we must return either the old translation or the new translation. This
isn't compatible with the Mux1H approach. So, flush the TLB and report
a miss on duplicate entries.
This is simpler, reduces what would have become a critical path in
the commit stage, and will make it easier to support the mbadinst
CSR if it is implemented.
We were zero-extending it, which is a double-precision zero in the recoded
format. So, when spilled and reloaded with fsd/fld, the original value
was destroyed. Instead, set the MSBs so that it represents sNaN. When
spilled, the single-precision number will be preserved as the NaN payload.
- Make API more idiomatic (x holdUnless y, instead of holdUnless(x, y))
- Add new SeqMem API, readAndHold, which corresponds to most common
use of holdUnless
PLRU wasn't implemented correctly for the BTB, since it wasn't
increasing the priority on replacement, only on usage. Regardless,
this should be a second-order effect, so using FIFO always is fine.
Andrew Waterman
