Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
The scheme was based on the notion that memory accesses are idempotent
up until the point the trigger would've been hit, which isn't true in
the case of side-effecting loads and data-value triggers.
Instead, check the trigger on the next instruction fetch. To keep the
perf overhead minimal, perform this check on the I$ refill path, and
ensure that path is taken by flushing the I$.
|
|
Instruction fetch is always little-endian.
|
|
|
|
|
|
As a side effect, misaligned stores now behave the same as aligned stores
with respect to triggers: only the first byte is checked.
|
|
As a side effect, misaligned loads now behave the same as aligned loads
with respect to triggers: only the first byte is checked.
|
|
|
|
Fix trigger priority
|
|
|
|
The data value of the function store_slow_path() is meaningful only when
the actually_store=true. Otherwise, the data value is a hollow value of
0, which may result in unintended trigger matching.
|
|
The spec defines that the mcontrol store address/data has a higher
priority over page fault and address misalignment (Debug spec, Table
5.2). Thus, the trigger checking should be before the translation and
alignment checking.
The previous implementation checks the trigger after the translation and
alignment, resulting in incorrect priority. For instance, when page fault
and trigger occur on the same instruction, the previous implementation
will choose to raise the page fault, which contradicts the priority
requirement.
This commit moves the trigger checking before the misaligned checking and
translation. The trigger will fire on the instruction instead of the page
fault in the above case.
|
|
The spec defines the mcontrol load address has a higher priority over
page fault and address misaligned (Debug spec, Table 5.2). Thus, the
trigger checking should be before the translation and alignment
checking.
The previous implementation checks the trigger after the translation
and alignment, resulting in incorrect priority. For instance, when page
fault and trigger occur on the same instruction, the previous
implementation will choose to raise the page fault, which contradicts
the priority requirement.
This commit adds an address-only trigger checking before the misaligned
checking and translation. The trigger will fire on the instruction
instead of the page fault in the above case.
|
|
The mcontrol trigger can select either address or data for checking. The
The selection decides the priority of the trigger. For instance, the
address trigger has a higher priority over the page fault, and the page
fault has a higher priority over the data trigger.
The previous implementation only has the checking functions for data
trigger, which results in incorrect priority of address trigger.
This commit adds a has_data argument to indicate address trigger and the
priority of the trigger.
|
|
See #990.
|
|
tablewalks
Fix issue #990.
|
|
|
|
Didn't want to make change in previous commit to isolate the change.
|
|
start of AMO.
This includes skipping store in store_slow_path.
Is okay to skip the mmio_store part too, since the access_fault for mmio_failure will be caught on the actual store.
The ordering for the mmio_access fault is irrelevant since it will occur after the TW faults, and load faults are converted to store faults.
Will catch any faults from the access but won't perform a store.
Since store permissions can only be granted if read permissions exist,
any store faults will occur before or at the same time as a load fault.
Thus this store permissions check is sufficient for properly catching the faults in an Amo access TW.
|
|
Will be used to check store attributes without actually performing the store.
Needed to AMO bug fix.
|
|
|
|
|
|
|
|
|
|
Based on this statement from priv spec 5.5.1 (regarding Sv39x4):
"Address bits 63:41 must all be zeros, or else a guest-page-fault
exception occurs."
|
|
|
|
This was much more complicated than the others because of the
mstatus.TVM and hstatus.VTVM bits, and because of the special
WARL-ness of satp that doesn't apply to vsatp.
It appears (based on reading the code) that the commitlog for these
two was problematic. CSRW to satp when V=1 was reporting a write to
satp instead of vsatp which was actually written. Also a CSRW to
vsatp looks like it was not being logged at all. Both problems
should be fixed now.
|
|
|
|
Spike does not support dynamic xlen today, but if it should in the
future, this will help identify all the code that needs to be updated.
|
|
|
|
Step 5 of plan in csrs.h.
This changes the commitlog to properly report when the architectural
`vsstatus` register is written, e.g. by `csrw sstatus` in VS-mode.
|
|
Step 3 of plan described in csrs.h.
|
|
Part of step 2 of plan described in csrs.h.
|
|
Part of step 2 of plan described in csrs.h.
|
|
Makes a mess out of the tracing though, because of how every toggle of
the VBit swaps mstatus and vsstatus.
|
|
We've already checked just a few lines up that proc is defined.
|
|
This was the last place outside of the csr_t hierarchy that pmpcfg was
being accessed.
|
|
Since that's what it was returning anyway.
|
|
|
|
Since match4() checks this now.
|
|
To simplify calling code.
|
|
This will enable further restructuring of these loops in mmu.cc in the
next commits.
|
|
|
|
|
|
|
|
See discussion at
https://github.com/riscv/riscv-isa-sim/commit/9cfc3e7fef7b29f6b53879d7c91c35459d9b493d#r55593451
|
|
|
|
Continuation of 80be4e21c3af7fe2966788ce538d3e3c3b0d60e3
|
|
into daniellustig-nonleaf_dau
|