Skip to content

Conversation

@paulusmack
Copy link
Collaborator

Fix bugs found in dcache, loadstore1 and execute1

FSCR[IC] should be set to 13 for a prefix unavailable interrupt, not 11.
To avoid this type of mistake, use the same symbols for setting IC as
for the bit numbers in the rest of FSCR.

Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Since commit c938246 ("dcache: Simplify addressing of the dcache
TLB", 2025-04-05), tlbie instructions have been sent down the
loadstore pipe with both req.dc_req and req.mmu_op set, so that the
tlbie gets sent both to the data cache and the MMU.  This is so that
the relevant TLB hit signals are set correctly in the dcache for a
single-page invalidation.  However, this means that loadstore1 was not
sending a completion to writeback for the tlbie.  Normally this
doesn't cause a problem, but if the tlbie is followed by an
instruction that is marked 'single-pipe' in the decode1 tables, such
as sync (any variant), decode2 will then stall forever waiting for the
tlbie to complete before issuing the following instruction.

To fix this, clear req.dc_req in the second loadstore stage for a
tlbie (actually for any MMU operation, but tlbie is the only
instruction that would have dc_req set).

Fixes: c938246 ("dcache: Simplify addressing of the dcache TLB", 2025-04-05)
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
If a touch is immediately followed by a load to a different address
which has the same index as the touch address, and both are cache
misses, it is possible for the load to be treated as if it is to the
same cache line as the touch, and thus return data from the line being
touched rather than the line being loaded from.  For example, if the
touch is to 0x1c20 and the load is to 0x2c20, and the state left in
r1.store_ways by an earlier operation happens to match the PLRU victim
way, the load will return data from 0x1c20.

This happens because the touch completes immediately, meaning that the
load gets processed before r1.store_ways and the cache tag for the
line being touched have been set correctly, leading to a chance that
the load can match when it shouldn't (or not match when it should).
To fix this, complete the touch after one cycle, in RELOAD_WAIT_ACK
state, rather than immediately.

Also, for touches, consider hit_reload = 1 equivalent to a cache hit.
If the line is being reloaded then the touch doesn't need to do
anything.

Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reading the LOG_DATA SPR is supposed to increment the log address,
and reading LOG_ADDR is not supposed to, but currently this is the
wrong way around.  Fix it.  Also add a related comment.

Fixes: 8f7326a ("core: Implement various SPRs which read zero and ignore writes", 2025-04-10)
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
…alue

If an scv (or sc) instruction is executed and an asynchronous
interrupt occurs on the following instruction (e.g. the first
instruction of the scv handler), the address written to SRR0 will be
the address of that following instruction + 4.  The reason is that
ex1.advance_nia will still be set from the execution of the sc[v].
Fix this by clearing v.advance_nia in execute1_1.

(This only shows up for asynchronous interrupts with scv, not sc,
because sc clears MSR[EE].  It should show up for synchronous
interrupts with both sc and scv, but that has not been demonstrated.)

Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
@paulusmack paulusmack merged commit d02e8e6 into antonblanchard:master Jan 10, 2026
21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant