On 2/27/26 10:27, Thomas Huth 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 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 > Hi Thomas,
Yes, sure, thanks for the advice, I will try to follow that part for riscv as well! Thanks a lot! Djordje
