Re: [PATCH v4 16/16] hw/riscv: Use the CPU to determine if 32-bit

[Palmer Dabbelt]

On Thu, 17 Dec 2020 05:58:11 PST (-0800), richard.henderson@linaro.org wrote:
> On 12/17/20 12:44 AM, Bin Meng wrote:
> > What happens if something like ARM big.LITTLE needs to be supported on RISC-V?
>
> I'd say it's the board's job to pass the boot heart.
> (Though even big.LITTLE doesn't mix 64 and 32-bit cores.)

I guess we can't stop people from building crazy things, but it does seem like
building a system that mixes up base ISAs is unlikely.  IDK if 32-bit
compatibility on 64-bit systems is ever going to be important enough to show up
on RISC-V, as 32-bit might be defunct in portable systems by the point real
RISC-V systems are availiable, but one could imagine systems where only a
subset of cores have 32-bit compatibility.  My guess is that they'd all boot
into 64-bit mode, though, so that sort of stuff won't be relevant until one
tries to get to 32-bit code.

Regardless of where that sort of thing goes, it seems reasonable to just ban
people from spinning up mixed machine XLEN systems in QEMU for the time being.
IIUC that's always been impossible (as it was a #define before), so it's not
like we're regressing on any functionality with that constraint.

Other hetergenous ISA/microarctucture stuff seems reasonable to support in
QEMU, but also not a high priority.  It doesn't seem that hard to write the
early boot stuff in a way such that it only depends on the base ISA -- that's
essentially how we're handling stuff like F/D in Linux, you just either probe
or handle the traps.  There's already some simple hetergenous stuff floating
around (like the non-MMU cores in the SiFive designs) and that all seems to
work fine so my guess is we have enough stuff there, but I'm sure there'll be
more work do to as more complicated designs start to show up (doubly so as
there's no specs for any of this).