On 9/29/25 7:03 PM, Philippe Mathieu-Daudé wrote:
On 30/9/25 00:44, Pierrick Bouvier wrote:
On 9/24/25 12:20 AM, Anton Johansson wrote:
Quick question to correct my understanding. AFAICT riscv64-softmmu is a
superset of riscv32-softmmu which handles 32-, 64, and 128-bit ISAs, so
concerning single-binary do we for the time being only need to support
riscv64-softmmu?
You are correct in that they are all part of the same architecture,
the register bits accessed being a mode of a CPU.
IMO The "superset" view comes from QEMU historical development, and
I suspect a generic riscv-softmmu could be sufficient here.
Overall, most of the changes you do are correct, widening types, and
combining low/high part in single 64 bits integer. For this last part,
I'll let Riscv maintainers decide if they agree with the approach.
However, the main issue is that changing size impacts migration
(VMSTATE_UINT.*), which would suddenly create a breaking change when
importing 32 bits machines.
We have two ways to deal with it:
1. call it a day and make a breaking change.
On Arm side, we were lucky to not have cpu structure defined with any
target type, so the problem was not found yet. But we observed that
other architectures would need a solution.
If Riscv maintainers are ok for a breaking change, this is the easiest/
fastest solution.
2. introduce a backward compatibility change, to selectively import size
if we import from a past QEMU version. In this case, we would keep the
VMSTATE_UINTTL but adapt it to do the right thing when restoring, either
writing 32 or 64 bits.
I didn't dive deep enough in migration restore code to see if it's
easily doable, or not.
IMHO we should really avoid (2). The only problematic architectures (wrt
migration) are PPC and X86.
Indeed, it looks like a nightmare and an excellent maintenance burden.
I saw after sending my email that Alistair was open to a breaking
change, so that's a good news!
