From: Paolo Bonzini <pbonzini@redhat.com>
To: Alistair Francis <alistair23@gmail.com>
Cc: qemu-devel@nongnu.org, alistair.francis@wdc.com
Subject: Re: [PATCH 00/22] target/riscv: declarative CPU definitions
Date: Tue, 18 Feb 2025 09:27:29 +0100 [thread overview]
Message-ID: <15e68aa7-0242-4ccf-ae7f-aea26f2c7b68@redhat.com> (raw)
In-Reply-To: <CAKmqyKNhc3WAkSee0TOsziKO8HJReg0qrxD04WXp3j90O=O9cQ@mail.gmail.com>
On 2/18/25 01:25, Alistair Francis wrote:
> On Fri, Feb 7, 2025 at 4:28 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>> Hi Alastair,
>>
>> the subject is a slightly underhanded description, in that what I really
>> wanted to achieve was removing RISC-V's use of .instance_post_init; that's
>> because RISC-V operate with an opposite conception of .instance_post_init
>> compared to everyone else: RISC-V wants to register properties there,
>> whereas x86 and hw/pci-bridge/pcie_root_port.c want to set them.
>> While it's possible to move RISC-V's code to instance_init, the others
>> have to run after global properties have been set by device_post_init().
>>
>> However, I think the result is an improvement anyway, in that it makes
>> CPU definitions entirely declarative. Previously, multiple instance_init
>> functions each override the properties that were set by the superclass,
>> and the code used a mix of subclassing and direct invocation of other
>> functions. Now, instead, after .class_init all the settings for each
>> model are available in a RISCVCPUDef struct, and the result is copied
>> into the RISCVCPU at .instance_init time. This is done with a single
>> function that starts from the parent's RISCVCPUDef and applies the delta
>> stored in the CPU's class_data.
>
> That is nice!
>
> I don't love the ifdef-ery around `#include "cpu_cfg_fields.h.inc"`
> but overall the patches look fine.
No problem, if you're okay with the final "target/riscv: move SATP modes
out of CPUConfig" I can move it earlier in the series and get rid of the
#ifdefs in cpu_cfg_fields.h.inc. It's only needed because satp_modes
are not merged by the class_init function (they're not even initialized
in fact).
>> Do you think this is a good approach?
>
> Seems fine to me :)
Ok, then I'll repost as soon as the patches for read-only class_data are
ready.
Paolo
prev parent reply other threads:[~2025-02-18 8:28 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-06 18:26 [PATCH 00/22] target/riscv: declarative CPU definitions Paolo Bonzini
2025-02-06 18:26 ` [PATCH 01/22] target/riscv: remove unused macro DEFINE_CPU Paolo Bonzini
2025-02-10 0:44 ` Alistair Francis
2025-02-06 18:26 ` [PATCH 02/22] target/riscv: introduce RISCVCPUDef Paolo Bonzini
2025-02-06 21:16 ` Richard Henderson
2025-02-09 18:44 ` Philippe Mathieu-Daudé
2025-02-09 18:53 ` Philippe Mathieu-Daudé
2025-02-09 22:20 ` Philippe Mathieu-Daudé
2025-02-09 22:32 ` Philippe Mathieu-Daudé
2025-02-06 18:26 ` [PATCH 03/22] target/riscv: store RISCVCPUDef struct directly in the class Paolo Bonzini
2025-02-18 0:02 ` Alistair Francis
2025-02-06 18:26 ` [PATCH 04/22] target/riscv: merge riscv_cpu_class_init with the class_base function Paolo Bonzini
2025-02-18 0:05 ` Alistair Francis
2025-02-06 18:26 ` [PATCH 05/22] target/riscv: move RISCVCPUConfig fields to a header file Paolo Bonzini
2025-02-18 0:06 ` Alistair Francis
2025-02-06 18:26 ` [PATCH 06/22] target/riscv: add more RISCVCPUDef fields Paolo Bonzini
2025-02-18 0:23 ` Alistair Francis
2025-02-18 9:30 ` Paolo Bonzini
2025-02-06 18:26 ` [PATCH 07/22] target/riscv: convert abstract CPU classes to RISCVCPUDef Paolo Bonzini
2025-02-06 18:26 ` [PATCH 08/22] target/riscv: convert profile CPU models " Paolo Bonzini
2025-02-06 18:26 ` [PATCH 09/22] target/riscv: convert bare " Paolo Bonzini
2025-02-06 18:26 ` [PATCH 10/22] target/riscv: move 128-bit check to TCG realize Paolo Bonzini
2025-02-06 18:26 ` [PATCH 11/22] target/riscv: convert dynamic CPU models to RISCVCPUDef Paolo Bonzini
2025-02-06 18:27 ` [PATCH 12/22] target/riscv: convert SiFive E " Paolo Bonzini
2025-02-06 18:27 ` [PATCH 13/22] target/riscv: convert ibex " Paolo Bonzini
2025-02-06 18:27 ` [PATCH 14/22] target/riscv: convert SiFive U " Paolo Bonzini
2025-02-06 18:27 ` [PATCH 15/22] target/riscv: th: make CSR insertion test a bit more intuitive Paolo Bonzini
2025-02-06 18:27 ` [PATCH 16/22] target/riscv: generalize custom CSR functionality Paolo Bonzini
2025-02-06 18:27 ` [PATCH 17/22] target/riscv: convert TT C906 to RISCVCPUDef Paolo Bonzini
2025-02-06 18:27 ` [PATCH 18/22] target/riscv: convert TT Ascalon " Paolo Bonzini
2025-02-06 18:27 ` [PATCH 19/22] target/riscv: convert Ventana V1 " Paolo Bonzini
2025-02-06 18:27 ` [PATCH 20/22] target/riscv: convert Xiangshan Nanhu " Paolo Bonzini
2025-02-06 18:27 ` [PATCH 21/22] target/riscv: remove .instance_post_init Paolo Bonzini
2025-02-06 18:27 ` [PATCH 22/22] target/riscv: move SATP modes out of CPUConfig Paolo Bonzini
2025-02-18 0:25 ` [PATCH 00/22] target/riscv: declarative CPU definitions Alistair Francis
2025-02-18 8:27 ` Paolo Bonzini [this message]
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=15e68aa7-0242-4ccf-ae7f-aea26f2c7b68@redhat.com \
--to=pbonzini@redhat.com \
--cc=alistair.francis@wdc.com \
--cc=alistair23@gmail.com \
--cc=qemu-devel@nongnu.org \
/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).