On Wed, Feb 25, 2026 at 10:30 PM Daniel P. Berrangé <[email protected]> wrote: > > On Wed, Feb 25, 2026 at 11:39:50AM +0100, Thomas Huth wrote: > > On 25/02/2026 11.20, Djordje Todorovic wrote: > > > Add options to compile riscv64be-softmmu and riscv32be-softmmu > > > --- > > > meson.build | 7 ++++++- > > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > > > diff --git a/meson.build b/meson.build > > > index 8c6c0a9a32..41ad38d184 100644 > > > --- a/meson.build > > > +++ b/meson.build > > > @@ -55,6 +55,11 @@ supported_cpus = ['ppc64', 's390x', 'riscv64', > > > 'x86_64', > > > cpu = host_machine.cpu_family() > > > +# Unify riscv64be to riscv64. > > > +if cpu == 'riscv64be' > > > + cpu = 'riscv64' > > > +endif > > > + > > > target_dirs = config_host['TARGET_DIRS'].split() > > > # type of binaries to build > > > @@ -281,7 +286,7 @@ elif cpu == 'ppc64' > > > elif cpu == 'mips64' > > > kvm_targets = ['mips-softmmu', 'mipsel-softmmu', 'mips64-softmmu', > > > 'mips64el-softmmu'] > > > elif cpu == 'riscv64' > > > - kvm_targets = ['riscv64-softmmu'] > > > + kvm_targets = ['riscv32-softmmu', 'riscv64-softmmu', > > > 'riscv32be-softmmu', 'riscv64be-softmmu']
We really don't want a 32-bit KVM target at all > > > > I really dislike the idea of having yet another target like mips where we > > have 4 different flavours (32/64 bits x big/little endian). That increases > > the compile- and testing time a lot. Couldn't you do it the ppc64 way? The > > ppc64-softmmu target can handle both, big and little endian, no need for a > > separate binary here. And we are going the same way with microblaze now - > > the microblaze target recently got support for little endian, so we can > > finally get rid of the microblazeel target now. > > Also with the ongoing work to make a single QEMU binary that can > support any target, it feels like any problems with handling big > and little endian in a single binary will need to be solved > regardless, so if practical we should align with that direction > from the start. Exactly. We are working towards a single RISC-V binary for all bit lengths. Big endian would have to start out included in the existing builds Alistair > > > With regards, > Daniel > -- > |: https://berrange.com ~~ https://hachyderm.io/@berrange :| > |: https://libvirt.org ~~ https://entangle-photo.org :| > |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :| >
