qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] QEMU fails to build on MIPS


From: Peter Maydell
Subject: [Qemu-devel] QEMU fails to build on MIPS
Date: Fri, 13 Apr 2018 12:51:45 +0100

mst pointed this out, and I can reproduce it. (I don't have MIPS
in my set of build targets for pull requests because I don't have
access to any sufficiently fast MIPS hosts.)

In file included from /home/pm215/qemu/include/qemu/osdep.h:36:0,
                 from /home/pm215/qemu/tcg/tcg.c:28:
/home/pm215/qemu/tcg/mips/tcg-target.inc.c: In function ‘tcg_out_tlb_load’:
/home/pm215/qemu/include/qemu/compiler.h:90:36: error: static
assertion failed: "not expecting: offsetof(CPUArchState,
tlb_table[NB_MMU_MODES - 1][1]) > 0x7ff0 + 0x7fff"
 #define QEMU_BUILD_BUG_MSG(x, msg) _Static_assert(!(x), msg)
                                    ^
/home/pm215/qemu/include/qemu/compiler.h:98:30: note: in expansion of
macro ‘QEMU_BUILD_BUG_MSG’
 #define QEMU_BUILD_BUG_ON(x) QEMU_BUILD_BUG_MSG(x, "not expecting: " #x)
                              ^
/home/pm215/qemu/tcg/mips/tcg-target.inc.c:1236:9: note: in expansion
of macro ‘QEMU_BUILD_BUG_ON’
         QEMU_BUILD_BUG_ON(offsetof(CPUArchState,
         ^
/home/pm215/qemu/rules.mak:66: recipe for target 'tcg/tcg.o' failed


This has happened because for AArch64 the offset of the tlb_table
from the start of the CPUArchState is now too large:

(gdb) print &((CPUARMState*)(0))->tlb_table[7][1]
$3 = (CPUTLBEntry *) 0x10d80

Does anybody have a good suggestion for a fix? We could just
make the codegen for MIPS TCG tcg_out_tlb_load() cope with the
larger offset, at the cost of an extra insn in the fast path.

Moving the tlb_table to earlier in the CPU state structure
seems like a nicer long term approach, but is awkward because
it would mean moving it from the "not cleared on CPU reset"
part of the struct into the "zeroed out on CPU reset" part.
I don't know if that would be safe or not...

(Has nobody been testing with MIPS hosts? I'm surprised
we got to rc3 without anybody spotting this...)

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]