[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH v5 0/4] riscv: Add support for Zicbo[m,z,p] instructions

From: Daniel Henrique Barboza
Subject: [PATCH v5 0/4] riscv: Add support for Zicbo[m,z,p] instructions
Date: Wed, 15 Feb 2023 17:59:07 -0300


This is the v5 of the patch series sent by Christoph Muellner one year
ago [1]. Aside from a code rebase on top of Alistair's
riscv-to-apply.next I also tried to implement the suggestions given in
the reviews.

Patch 1 is unchanged, aside from trivial changes due to code rebasing.
Patch 2 from v4 was split in 3, one CBO extension per patch.

Patch 4 contains the placeholder for the Zicbop prefetch instructions.
Not much to be said.

Patch 2 contains the code for Zicboz. It contains common code that is
used by Zicbom later on, so adding it first makes our lives a bit
easier. Aside from a function rename (helper_zicbo_envcfg is now
check_zicbo_envcfg) and style fixes, the code is unchanged.

Patch 3 contains Zicbom. The function check_zicbom_access (renamed from
helper_zicbom_access) got changed based on review comments and spec
changes in cmobase v1.0.1. We're now not checking for MMU_INST_FETCH
faults since the access for the cache-block is determined only by a load
or a store instruction. If neither of those are permitted, meaning the
access to the cache block isn't permitted, we're raising an appropriate
exception manually. In case we got that far, rely on
probe_access_range_flags() with nonfault=false to get any other faults,
PMP related or not.

This approach allows introducing Zicbom right away since we're not
leaving any exception/faults behind. The alternative, if we would like
to check for PMP faults by hand, is to refactor riscv_cpu_tlb_fill() to
extract the PMP relevant code in a separated helper. Given that cmobase
v1.0.1 does not dictate whether a PMP fault has a higher priority than
the store page faults, and we're not skipping any faults/exceptions, I
don't think this refactor is needed right now.

Changes from v4:
- patch 1: no changes, just a rebase
- former patch 2: split into 3 patches
- patch 2:
  - renamed helper_zicbo_envcfg to check_zicbo_envcfg 
  - added an ISA_EXT_DATA_ENTRY for ext_icboz
- patch 3: 
  - renamed helper_zicbom_access to check_zicbom_access
  - do not check for MMU_INST_FETCH to avoid modelling an unspecified
  - manually raise a store fault if load and store is not permitted
  - call probe_access_range_flags() with nonfault = false to catch any
    remaining exceptions
  - add back the "we don't emulate the cache hierarchy so we're done"
    comment in helper_cbo_clean_flush/inval 
v4 link: 

Previous versions history:

v3: https://lists.gnu.org/archive/html/qemu-devel/2022-02/msg02382.html
v2: https://lists.gnu.org/archive/html/qemu-devel/2022-01/msg04959.html
v1: https://lists.gnu.org/archive/html/qemu-devel/2022-01/msg03874.html

[1] https://lore.kernel.org/all/20220216154839.1024927-1-cmuellner@linux.com/T/

Christoph Muellner (4):
  accel/tcg: Add probe_access_range_flags interface
  target/riscv: implement Zicboz extension
  target/riscv: implement Zicbom extension
  target/riscv: add Zicbop cbo.prefetch{i,r,m} placeholder

 accel/tcg/cputlb.c                          |  19 +++
 accel/tcg/user-exec.c                       |  15 +-
 include/exec/exec-all.h                     |  24 +++
 target/riscv/cpu.c                          |   7 +
 target/riscv/cpu.h                          |   4 +
 target/riscv/helper.h                       |   5 +
 target/riscv/insn32.decode                  |  16 +-
 target/riscv/insn_trans/trans_rvzicbo.c.inc |  57 +++++++
 target/riscv/op_helper.c                    | 160 ++++++++++++++++++++
 target/riscv/translate.c                    |   1 +
 10 files changed, 304 insertions(+), 4 deletions(-)
 create mode 100644 target/riscv/insn_trans/trans_rvzicbo.c.inc


reply via email to

[Prev in Thread] Current Thread [Next in Thread]