Commit graph

9 commits

Author SHA1 Message Date
Atish Patra e54d0916ef target/riscv/pmp: Raise exception if no PMP entry is configured
As per the privilege specification, any access from S/U mode should fail
if no pmp region is configured.

Backports d102f19a2085ac931cb998e6153b73248cca49f1
2021-03-08 15:39:55 -05:00
Zong Li 9792907bcf target/riscv: Change the TLB page size depends on PMP entries.
The minimum granularity of PMP is 4 bytes, it is small than 4KB page
size, therefore, the pmp checking would be ignored if its range doesn't
start from the alignment of one page. This patch detects the pmp entries
and sets the small page size to TLB if there is a PMP entry which cover
the page size.

Backports af3fc195e3c8e98b62eca3e4ee927f1965381dc3
2021-03-08 12:46:27 -05:00
Hou Weiying 55be7adad9 riscv: Fix bug in setting pmpcfg CSR for RISCV64
First, sizeof(target_ulong) equals to 4 on riscv32, so this change
does not change the function on riscv32. Second, sizeof(target_ulong)
equals to 8 on riscv64, and 'reg_index * 8 + i' is not a legal
pmp_index (we will explain later), which should be 'reg_index * 4 + i'.

If the parameter reg_index equals to 2 (means that we will change the
value of pmpcfg2, or the second pmpcfg on riscv64), then
pmpcfg_csr_write(env, 2, val) will map write tasks to
pmp_write_cfg(env, 2 * 8 + [0...7], val). However, no cfg csr is indexed
by value 16 or 23 on riscv64, so we consider it as a bug.

We are looking for constant (e.g., define a new constant named
RISCV_WORD_SIZE) in QEMU to help others understand code better,
but none was found. A possible good explanation of this literal is it is
the minimum word length on riscv is 4 bytes (32 bit).

Backports fdd33b86b20d153b131fc6259aea7a0084ab14b8
2021-03-08 12:42:12 -05:00
Alexandre Mergnat cd956f5aa6 target/riscv: Fix pmp NA4 implementation
The end address calculation for NA4 mode is wrong because the address
used isn't shifted.

It doesn't watch 4 bytes but a huge range because the end address
calculation is wrong.

The solution is to use the shifted address calculated for start address
variable.

Modifications are tested on Zephyr OS userspace test suite which works
for other RISC-V boards (E31 and E34 core).

Backports cfad709bceb629a4ebeb5d8a3acd1871b9a6436b
2021-03-08 12:14:51 -05:00
Hesham Almatary e648455989
RISC-V: Fix a PMP bug where it succeeds even if PMP entry is off
The current implementation returns 1 (PMP check success) if the address is in
range even if the PMP entry is off. This is a bug.

For example, if there is a PMP check in S-Mode which is in range, but its PMP
entry is off, this will succeed, which it should not.

The patch fixes this bug by only checking the PMP permissions if the address is
in range and its corresponding PMP entry it not off. Otherwise, it will keep
the ret = -1 which will be checked and handled correctly at the end of the
function.

Backports commit f8162068f18f2f264a0355938784f54089234211 from qemu
2019-08-08 16:55:52 -04:00
Hesham Almatary 614c2954b0
RISC-V: Check for the effective memory privilege mode during PMP checks
The current PMP check function checks for env->priv which is not the effective
memory privilege mode.

For example, mstatus.MPRV could be set while executing in M-Mode, and in that
case the privilege mode for the PMP check should be S-Mode rather than M-Mode
(in env->priv) if mstatus.MPP == PRV_S.

This patch passes the effective memory privilege mode to the PMP check.
Functions that call the PMP check should pass the correct memory privilege mode
after reading mstatus' MPRV/MPP or hstatus.SPRV (if Hypervisor mode exists).

Backports commit cc0fdb298517ce56c770803447f8b02a90271152 from qemu
2019-08-08 16:52:57 -04:00
Dayeol Lee 6528c78fd5
target/riscv: Fix PMP range boundary address bug
A wrong address is passed to `pmp_is_in_range` while checking if a
memory access is within a PMP range.
Since the ending address of the pmp range (i.e., pmp_state.addr[i].ea)
is set to the last address in the range (i.e., pmp base + pmp size - 1),
memory accesses containg the last address in the range will always fail.

For example, assume that a PMP range is 4KB from 0x87654000 such that
the last address within the range is 0x87654fff.
1-byte access to 0x87654fff should be considered to be fully inside the
PMP range.
However the access now fails and complains partial inclusion because
pmp_is_in_range(env, i, addr + size) returns 0 whereas
pmp_is_in_range(env, i, addr) returns 1.

Backports commit 49db9fa1fd7c252596b53cf80876e06f407d09ed from qemu
2019-08-08 16:42:24 -04:00
Alistair Francis a4f2dcde28
riscv: pmp: Log pmp access errors as guest errors
Backports commit aad5ac2311f3ad2c0be12d0eaaf4ef4398438fc2 from qemu
2019-03-19 23:45:03 -04:00
Lioncash b6f752970b
target/riscv: Initial introduction of the RISC-V target
This ports over the RISC-V architecture from Qemu. This is currently a
very barebones transition. No code hooking or any fancy stuff.
Currently, you can feed it instructions and query the CPU state itself.

This also allows choosing whether or not RISC-V 32-bit or RISC-V 64-bit
is desirable through Unicorn's interface as well.

Extremely basic examples of executing a single instruction have been
added to the samples directory to help demonstrate how to use the basic
functionality.
2019-03-08 21:46:10 -05:00