On 2/18/25 01:25, Alistair Francis wrote:
On Fri, Feb 7, 2025 at 4:28 AM Paolo Bonzini <pbonz...@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
