qemu-riscv
[Top][All Lists]
Advanced

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

Re: [PATCH v4 3/5] target/riscv: Move misa_mxl_max to class


From: Akihiko Odaki
Subject: Re: [PATCH v4 3/5] target/riscv: Move misa_mxl_max to class
Date: Thu, 19 Oct 2023 19:17:28 +0900
User-agent: Mozilla Thunderbird

On 2023/10/18 23:23, Daniel Henrique Barboza wrote:


On 10/18/23 10:31, Akihiko Odaki wrote:
On 2023/10/18 22:01, Daniel Henrique Barboza wrote:


On 10/17/23 15:53, Akihiko Odaki wrote:
misa_mxl_max is 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>
---

I'll repeat what I said in the v1: this patch is adding an extra class parameter, an extra param required to each class_init, and an extra CPUClass cast every time we want to read misa_mxl_max, all of that because we want to assign gdb_core_xml_file
earlier.

If my previous suggestion of assigning gdb_core directly into riscv_cpu_class_init() doesn't work necause we need misa_mxl_max to do it, a good alternative is setting gdb_core_xml_file in riscv_cpu_post_init(), which is executed after all cpu_init()
functions where we already have env->misa_mxl_max set properly.

We want to assign gdb_core_xml_file *earlier* so assigning it after cpu_init() is not OK. In general it should be considered unsafe to initialize a class variable after class_init(); otherwise other subsystems cannot know when it becomes available.

There's no difference in assigning it during .instance_init (cpu_init()) and
.instance_post_init. The callbacks are called one after the other during
init time. See qom/object.c,  object_initialize_with_type().

Now, if we want to be strict with only initializing class variables during class_init(), which is something that I will defer to the maintainers, we want to minimize the use of env->misa_mxl_max in the code before converting it to a class variable. env->misa_mxl is always equal to env->misa_mxl_max, and they are being used interchangeably, but if misa_mxl_max is going to be a class variable then we want to use env->misa_mxl instead
to avoid the RISCV_CPU_GET_CLASS() overhead.

I suggest a pre-patch to change the uses of env->misa_mxl_max to env->misa_mxl in riscv_is_32bit(), riscv_cpu_gdb_read_register(), riscv_cpu_gdb_write_register() and so on (there are quite a few places). And then apply this patch on top of it. This would
at least minimize the amount of casts being done.

misa_mxl and misa_mxl_max may be same for now, but they exist because they will be different in the future; otherwise there is no reason to have misa_mxl_max at the first place. misa_mxl represents the current effective value and misa_mxl_max represents the maximum value the emulated CPU supports.

So we need to preserve the existing choice of misa_mxl and misa_mxl_max in general. riscv_cpu_gdb_read_register() and riscv_cpu_gdb_write_register(), for example, must use misa_mxl_max instead of misa_mxl since GDB doesn't support changing register width at runtime, and the register width should match with the feature description provided by gdb_core_xml_file.

The use of env->misa_mxl_max in riscv_is_32bit(), however, looks not good to me. If a 64-bit processor is in 32-bit mode, the 32-bit kernel should be loaded. I added a patch to change it to env->misa_mxl in v5.


All this considered, there's still one extra class cast that we will have to deal with in riscv_tr_init_disas_context(). I am not sure how hot this function is but, taking a look at other .init_disas_context implementations from other archs and not finding class casts in them, I'm worried about the overhead it'll add. It seems like we can just do
"ctx->misa_mxl_max = env->misa_mxl" to avoid it.

The cost of the class type check should be negligible considering that init_disas_context() is followed by the TCG translation, which takes most of execution time.



reply via email to

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