On Mon, Jul 27, 2026 at 9:52 AM Richard Henderson <[email protected]> wrote: > > On 7/27/26 04:48, Laurent Vivier wrote: > > On real SH4 hardware, the address space is split between user mode > > (U0, 0x00000000-0x7fffffff) and kernel mode (P1-P4, 0x80000000-0xffffffff), > > so TARGET_VIRT_ADDR_SPACE_BITS was set to 31 for CONFIG_USER_ONLY. > > > > However, qemu-user does not emulate the MMU, so this limit is not needed. > > The only effect is to restrict reserved_va to 2 GB, causing OOM failures > > for memory-intensive builds (e.g. webkit2gtk on Debian sh4 buildds). > > > > Set TARGET_VIRT_ADDR_SPACE_BITS to 32 unconditionally, like most other > > 32-bit targets. Also fix the TASK_UNMAPPED_BASE macro to use 1ull instead > > of 1u to avoid undefined behavior when shifting by 32. > > > > Reported-by: John Paul Adrian Glaubitz <[email protected]> > > Signed-off-by: Laurent Vivier <[email protected]> > > --- > > linux-user/sh4/target_mman.h | 2 +- > > target/sh4/cpu-param.h | 6 +----- > > 2 files changed, 2 insertions(+), 6 deletions(-) > > So, the goal is to run things under qemu-linux-user that can't run on > hardware? > > I'm not necessarily opposed, though there have been software systems that > know that the > upper bit is unused and reuse it for tagged pointers. Emacs did so, sometime > last > century. I'm sure there were others. Anyway that's the reason we currently > limit > qemu-linux-user like the hardware does. > > If you're going to drop that, you might do this for all targets: > > mips/cpu-param.h:# define TARGET_VIRT_ADDR_SPACE_BITS 31 > sh4/cpu-param.h:# define TARGET_VIRT_ADDR_SPACE_BITS 31 > xtensa/cpu-param.h:#define TARGET_VIRT_ADDR_SPACE_BITS 30
Xtensa has it for the different reason: with the windowed call ABI it cannot have calls between regions that have addresses with different two topmost bits. call0 ABI doesn't have this limitation. -- Thanks. -- Max
