Skip to contentSkip to conversation

sh4: define explicitly that the target CPU is 32 bit

PATCH In review Carlo Marcelo Arenas Belon 4 participants 6 messages Nov 30, 2007 – Dec 1, 2007

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 sh4: define explicitly that the target CPU is 32 bit

The following patch enforces that the sh4 target is 32 bit to prevent qemu to expand incorrectly to a 64 bit wide cpu if compiled in a 64 bit host.

Carlo

---
Index: target-sh4/cpu.h
===================================================================
RCS file: /sources/qemu/qemu/target-sh4/cpu.h,v
retrieving revision 1.12

cpu.h +1 -0
diff -u -r1.12 cpu.h
@@ -22,6 +22,7 @@
 
 #include "config.h"
 
+#define TARGET_PHYS_ADDR_BITS 32
 #define TARGET_LONG_BITS 32
 #define TARGET_HAS_ICE 1
 
#1 lore raw
Quoted 2 lines · Carlo Marcelo Arenas Belon

The following patch enforces that the sh4 target is 32 bit to prevent qemu to expand incorrectly to a 64 bit wide cpu if compiled in a 64 bit host.

This is wrong. As the comment in cpu-defs.h says, target_phys_addr_t may need to be bigger than the actual target address space.

What exactly are you trying to fix?

Paul

#2 lore raw
Quoted 8 lines · Paul Brook
Quoted 2 lines · Carlo Marcelo Arenas Belon

The following patch enforces that the sh4 target is 32 bit to prevent qemu to expand incorrectly to a 64 bit wide cpu if compiled in a 64 bit host.

This is wrong. As the comment in cpu-defs.h says, target_phys_addr_t may need to be bigger than the actual target address space.

What exactly are you trying to fix?

in a generic way, that the CPU width of the host (as defined by the size of the type that is used to store a target_phys_addr_t) that is used to build the emulator affects in any way the size of the emulated target physical address size or its representation.

in the sh4 specific case, it doesn't make sense for sh4 to print an access error to a physical address that is 64 bit long when it is a 32 bit CPU and that is what would happen unless the patch is applied.

if anything the following definition from cpu-defs.h is invalid for a representation of a 32 bit physical address :

#define TARGET_FMT_plx "%016" PRIx64

Carlo

#3 lore raw
Quoted 16 lines · Carlo Marcelo Arenas Belon
Quoted 9 lines · Paul Brook
Quoted 3 lines · Carlo Marcelo Arenas Belon

The following patch enforces that the sh4 target is 32 bit to prevent qemu to expand incorrectly to a 64 bit wide cpu if compiled in a 64 bit host.

This is wrong. As the comment in cpu-defs.h says, target_phys_addr_t may need to be bigger than the actual target address space.

What exactly are you trying to fix?

in a generic way, that the CPU width of the host (as defined by the size of the type that is used to store a target_phys_addr_t) that is used to build the emulator affects in any way the size of the emulated target physical address size or its representation.

Quoted 8 lines

in the sh4 specific case, it doesn't make sense for sh4 to print an access error to a physical address that is 64 bit long when it is a 32 bit CPU and that is what would happen unless the patch is applied.

if anything the following definition from cpu-defs.h is invalid for a representation of a 32 bit physical address :

#define TARGET_FMT_plx "%016" PRIx64

Before you can fix that you probably need to fix the bits of qemu (TLB code) that store a host pointer in a phys_addr_t. Or at least distance TARGET_PHYS_ADDR_BITS from the definition of phys_addr_t, and include appropriate comments.

In that case TARGET_PHYS_ADDR_BITS could be a precise value, rather than the next multiple of 32. e.g. I think sparc32 has a 40-bit physical address space.

Paul

#4 lore raw
Quoted 26 lines · Paul Brook
Quoted 16 lines · Carlo Marcelo Arenas Belon
Quoted 9 lines · Paul Brook
Quoted 3 lines · Carlo Marcelo Arenas Belon

The following patch enforces that the sh4 target is 32 bit to prevent qemu to expand incorrectly to a 64 bit wide cpu if compiled in a 64 bit host.

This is wrong. As the comment in cpu-defs.h says, target_phys_addr_t may need to be bigger than the actual target address space.

What exactly are you trying to fix?

in a generic way, that the CPU width of the host (as defined by the size of the type that is used to store a target_phys_addr_t) that is used to build the emulator affects in any way the size of the emulated target physical address size or its representation.

Quoted 8 lines

in the sh4 specific case, it doesn't make sense for sh4 to print an access error to a physical address that is 64 bit long when it is a 32 bit CPU and that is what would happen unless the patch is applied.

if anything the following definition from cpu-defs.h is invalid for a representation of a 32 bit physical address :

#define TARGET_FMT_plx "%016" PRIx64

Quoted 8 lines

Before you can fix that you probably need to fix the bits of qemu (TLB code) that store a host pointer in a phys_addr_t. Or at least distance TARGET_PHYS_ADDR_BITS from the definition of phys_addr_t, and include appropriate comments.

In that case TARGET_PHYS_ADDR_BITS could be a precise value, rather than the next multiple of 32. e.g. I think sparc32 has a 40-bit physical address space.

36 bits. ASI bits could be included to address bits in order to simplify the ASI handling, then the sum would be 43 or 44.

#5 lore raw
In reply to Paul Brook
Quoted 11 lines · Paul Brook
Quoted 9 lines · Carlo Marcelo Arenas Belon

On Fri, Nov 30, 2007 at 04:28:09PM +0000, Paul Brook wrote:
in the sh4 specific case, it doesn't make sense for sh4 to print an access error to a physical address that is 64 bit long when it is a 32 bit CPU and that is what would happen unless the patch is applied.

if anything the following definition from cpu-defs.h is invalid for a representation of a 32 bit physical address :

#define TARGET_FMT_plx "%016" PRIx64

Quoted 9 lines

Before you can fix that you probably need to fix the bits of qemu (TLB code) that store a host pointer in a phys_addr_t. Or at least distance TARGET_PHYS_ADDR_BITS from the definition of phys_addr_t, and include appropriate comments.

In that case TARGET_PHYS_ADDR_BITS could be a precise value, rather than the next multiple of 32. e.g. I think sparc32 has a 40-bit physical address space.

It also depends on how precise you want to make this. SH has configurable 29-bit and 32-bit physical, while MIPS and PPC both have 32 and 36-bit physical implementations. Setting things to an arbitrary upper ceiling at least prevents this from quickly entering ifdef hell territory.