From: "Alex Bennée" <alex.bennee@linaro.org>
To: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: "Mikhail Tyutin" <m.tyutin@yadro.com>,
"Aleksandr Anenkov" <a.anenkov@yadro.com>,
qemu-devel@nongnu.org,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Alistair Francis" <alistair.francis@wdc.com>,
"Bin Meng" <bin.meng@windriver.com>,
"Weiwei Li" <liweiwei@iscas.ac.cn>,
"Daniel Henrique Barboza" <dbarboza@ventanamicro.com>,
"Liu Zhiwei" <zhiwei_liu@linux.alibaba.com>,
"open list:RISC-V TCG CPUs" <qemu-riscv@nongnu.org>
Subject: Re: [PATCH v9 01/23] target/riscv: Move MISA limits to class
Date: Wed, 11 Oct 2023 16:23:15 +0100 [thread overview]
Message-ID: <871qe1p40c.fsf@linaro.org> (raw)
In-Reply-To: <20231011070335.14398-2-akihiko.odaki@daynix.com>
Akihiko Odaki <akihiko.odaki@daynix.com> writes:
> MISA limits are common for all instances of a RISC-V CPU class so they
> are better put into class.
>
> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> ---
> target/riscv/cpu-qom.h | 2 +
> target/riscv/cpu.h | 2 -
> hw/riscv/boot.c | 2 +-
> target/riscv/cpu.c | 212 +++++++++++++++++++++++++++------------
> target/riscv/csr.c | 3 +-
> target/riscv/gdbstub.c | 12 ++-
> target/riscv/machine.c | 11 +-
> target/riscv/translate.c | 3 +-
> 8 files changed, 167 insertions(+), 80 deletions(-)
>
> diff --git a/target/riscv/cpu-qom.h b/target/riscv/cpu-qom.h
> index 04af50983e..266a07f5be 100644
> --- a/target/riscv/cpu-qom.h
> +++ b/target/riscv/cpu-qom.h
> @@ -67,5 +67,7 @@ struct RISCVCPUClass {
> /*< public >*/
> DeviceRealize parent_realize;
> ResettablePhases parent_phases;
> + uint32_t misa_mxl_max; /* max mxl for this cpu */
> + uint32_t misa_ext_mask; /* max ext for this cpu */
> };
> #endif /* RISCV_CPU_QOM_H */
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index ef9cf21c0c..9f9cb6cd2a 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -155,9 +155,7 @@ struct CPUArchState {
>
> /* RISCVMXL, but uint32_t for vmstate migration */
> uint32_t misa_mxl; /* current mxl */
> - uint32_t misa_mxl_max; /* max mxl for this cpu */
> uint32_t misa_ext; /* current extensions */
> - uint32_t misa_ext_mask; /* max ext for this cpu */
> uint32_t xl; /* current xlen */
>
> /* 128-bit helpers upper part return value */
> diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
> index 52bf8e67de..b7cf08f479 100644
> --- a/hw/riscv/boot.c
> +++ b/hw/riscv/boot.c
> @@ -36,7 +36,7 @@
>
> bool riscv_is_32bit(RISCVHartArrayState *harts)
> {
> - return harts->harts[0].env.misa_mxl_max == MXL_RV32;
> + return RISCV_CPU_GET_CLASS(&harts->harts[0])->misa_mxl_max ==
> MXL_RV32;
I'm going to defer to the RISCV maintainers here. While I agree the
class is a good place for these parameters that are shared across
multiple vCPUS there is a cost to RISCV_CPU_GET_CLASS() casting.
You might notice we have this comment in include/hw/core/cpu.h:
/*
* The class checkers bring in CPU_GET_CLASS() which is potentially
* expensive given the eventual call to
* object_class_dynamic_cast_assert(). Because of this the CPUState
* has a cached value for the class in cs->cc which is set up in
* cpu_exec_realizefn() for use in hot code paths.
*/
typedef struct CPUClass CPUClass;
DECLARE_CLASS_CHECKERS(CPUClass, CPU,
TYPE_CPU)
However I think you need to check the assumption that you will never see
multiple cores with different RISCV properties.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2023-10-11 15:35 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-11 7:02 [PATCH v9 00/23] plugins: Allow to read registers Akihiko Odaki
2023-10-11 7:02 ` [PATCH v9 01/23] target/riscv: Move MISA limits to class Akihiko Odaki
2023-10-11 15:23 ` Alex Bennée [this message]
2023-10-12 6:01 ` Akihiko Odaki
2023-10-11 16:04 ` Alex Bennée
2023-10-12 19:10 ` Daniel Henrique Barboza
2023-10-12 21:04 ` Akihiko Odaki
2023-10-11 7:02 ` [PATCH v9 02/23] target/riscv: Remove misa_mxl validation Akihiko Odaki
2023-10-11 7:02 ` [PATCH v9 03/23] target/riscv: Validate misa_mxl_max only once Akihiko Odaki
2023-10-11 7:02 ` [PATCH v9 04/23] gdbstub: Add num_regs member to GDBFeature Akihiko Odaki
2023-10-11 7:02 ` [PATCH v9 05/23] gdbstub: Introduce gdb_find_static_feature() Akihiko Odaki
2023-10-11 7:02 ` [PATCH v9 06/23] gdbstub: Introduce GDBFeatureBuilder Akihiko Odaki
2023-10-11 15:39 ` Alex Bennée
2023-10-11 7:02 ` [PATCH v9 07/23] target/arm: Use GDBFeature for dynamic XML Akihiko Odaki
2023-10-11 7:02 ` [PATCH v9 08/23] target/ppc: " Akihiko Odaki
2023-10-11 7:02 ` [PATCH v9 09/23] target/riscv: " Akihiko Odaki
2023-10-11 7:02 ` [PATCH v9 10/23] gdbstub: Use GDBFeature for gdb_register_coprocessor Akihiko Odaki
2023-10-11 7:02 ` [PATCH v9 11/23] gdbstub: Use GDBFeature for GDBRegisterState Akihiko Odaki
2023-10-11 15:57 ` Alex Bennée
2023-10-11 7:02 ` [PATCH v9 12/23] gdbstub: Change gdb_get_reg_cb and gdb_set_reg_cb Akihiko Odaki
2023-10-11 7:02 ` [PATCH v9 13/23] gdbstub: Simplify XML lookup Akihiko Odaki
2023-10-11 7:03 ` [PATCH v9 14/23] gdbstub: Infer number of core registers from XML Akihiko Odaki
2023-10-11 7:03 ` [PATCH v9 15/23] hw/core/cpu: Remove gdb_get_dynamic_xml member Akihiko Odaki
2023-10-11 7:03 ` [PATCH v9 16/23] gdbstub: Add members to identify registers to GDBFeature Akihiko Odaki
2023-10-11 7:03 ` [PATCH v9 17/23] gdbstub: Expose functions to read registers Akihiko Odaki
2023-10-11 7:03 ` [PATCH v9 18/23] cpu: Call plugin hooks only when ready Akihiko Odaki
2023-10-11 7:03 ` [PATCH v9 19/23] plugins: Remove an extra parameter Akihiko Odaki
2023-10-11 7:03 ` [PATCH v9 20/23] plugins: Use different helpers when reading registers Akihiko Odaki
2023-10-11 7:03 ` [PATCH v9 21/23] plugins: Allow to read registers Akihiko Odaki
2023-10-11 7:03 ` [PATCH v9 22/23] contrib/plugins: Allow to log registers Akihiko Odaki
2023-10-11 7:03 ` [PATCH v9 23/23] plugins: Support C++ Akihiko Odaki
2023-10-11 8:51 ` Daniel P. Berrangé
2023-10-11 15:48 ` Akihiko Odaki
2023-10-11 16:21 ` Thomas Huth
2023-10-11 16:42 ` Akihiko Odaki
2023-10-11 16:53 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871qe1p40c.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=a.anenkov@yadro.com \
--cc=akihiko.odaki@daynix.com \
--cc=alistair.francis@wdc.com \
--cc=bin.meng@windriver.com \
--cc=dbarboza@ventanamicro.com \
--cc=liweiwei@iscas.ac.cn \
--cc=m.tyutin@yadro.com \
--cc=palmer@dabbelt.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=zhiwei_liu@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).