On 27/02/2026 01.56, Alistair Francis wrote:
On Fri, Feb 27, 2026 at 9:47 AM Conor Dooley <[email protected]> wrote:
On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
<[email protected]> wrote:
On 25. Feb 2026, at 11:20, Djordje Todorovic <[email protected]>
wrote:
This series adds big-endian (BE) RISC-V target support to QEMU,
covering both softmmu and linux-user emulation for riscv32be and
riscv64be.
Hello,
There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
support it unless we’re sure that it can get to Linux upstream (for the
linux-user mode)?
Agreed. We really need upstream Linux support before user mode
On that front, Ben posted patches for it and Linus was really really not
enthused when he became aware of it:
https://lore.kernel.org/linux-riscv/[email protected]
Even without Linus' take, I feel like there's absolutely no chance of
upstream support without meaningful shipping hardware that requires
big endian support, because basically everyone else was also opposed to
adding it...
Yeah... I saw that.
A few thoughts, just because Linus doesn't like it doesn't mean QEMU
can't support it. But I am hesitant to support BE considering the lack
of ecosystem support everywhere else.
There are a bunch of changes in this series that could easily go into
QEMU. They aren't intrusive and just involve changing or using helper
functions to handle endianness. I think those could be split out and
go upstream, reducing the size of this series and reducing the
maintenance burden of out of tree patches.
The core BE support is a different problem. But if softmmu works in
the existing binaries then maybe it's worth accepting.
FWIW, have a look at the changes that Philippe did in target/microblaze/ in
the past two years, he merged the both endianness flavours there so it can
now be handled in one binary! If you do something similar with riscv, it
hopefully should not be too intrusive.
Thomas
