On Wed, Jan 18, 2023 at 10:28:46AM +1000, Alistair Francis wrote:
> On Wed, Jan 18, 2023 at 2:32 AM Andrew Jones <ajo...@ventanamicro.com> wrote:
> >
> > On Fri, Jan 13, 2023 at 11:34:53AM +0100, Alexandre Ghiti wrote:
...
> > > +
> > > + /* Get rid of 32-bit/64-bit incompatibility */
> > > + for (int i = 0; i < 16; ++i) {
> > > + if ((cpu->cfg.satp_mode.map & (1 << i)) && !valid_vm[i]) {
> >
> > If we ever define mode=1 for rv64, then 'sv32=on' will be incorrectly
> > accepted as an alias. I think we should simply not define the sv32
> > property for rv64 nor the rv64-only modes for rv32. So, down in
> > riscv_add_satp_mode_properties() we can add some
> >
> > #if defined(TARGET_RISCV32)
> > ...
> > #elif defined(TARGET_RISCV64)
> > ...
> > #endif
>
> Do not add any #if defined(TARGET_RISCV32) to QEMU.
>
> We are aiming for the riscv64-softmmu to be able to emulate 32-bit
> CPUs and compile time macros are the wrong solution here. Instead you
> can get the xlen of the hart and use that.
>
Does this mean we want to be able to do the following?
qemu-system-riscv64 -cpu rv32,sv32=on ...
If so, then can we move the object_property_add() for sv32 to
rv32_base_cpu_init() and the rest to rv64_base_cpu_init()?
Currently, that would be doing the same thing as proposed above,
since those functions are under TARGET_RISCV* defines, but I guess
the object_property_add()'s would then be in more or less the right
places for when the 32-bit emulation support work is started.
Thanks,
drew
