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. linux user mode is a whole other problem that we probably won't be able to accept. Alistair
