On 2/27/26 01:56, Alistair Francis wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > 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.
Please be aware that MIPS will ship hardware based on riscv BE soon: https://mips.com/products/hardware/i8500/ Thanks, Djordje > 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
