[Qemu-devel] [PATCH] sh4: define explicitly that the target CPU is 32 bit

[Qemu-devel] [PATCH] sh4: define explicitly that the target CPU is 32 bit

[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.

Carlo

---
Index: target-sh4/cpu.h
===================================================================
RCS file: /sources/qemu/qemu/target-sh4/cpu.h,v
retrieving revision 1.12
diff -u -r1.12 cpu.h
--- target-sh4/cpu.h	10 Nov 2007 15:15:53 -0000	1.12
+++ target-sh4/cpu.h	30 Nov 2007 16:08:38 -0000
@@ -22,6 +22,7 @@
 
 #include "config.h"
 
+#define TARGET_PHYS_ADDR_BITS 32
 #define TARGET_LONG_BITS 32
 #define TARGET_HAS_ICE 1
 

Re: [Qemu-devel] [PATCH] sh4: define explicitly that the target CPU is 32 bit

[Paul Brook]

On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> 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

Re: [Qemu-devel] [PATCH] sh4: define explicitly that the target CPU is 32 bit

[Carlo Marcelo Arenas Belon]

On Fri, Nov 30, 2007 at 04:28:09PM +0000, Paul Brook wrote:
> On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> > 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

Re: [Qemu-devel] [PATCH] sh4: define explicitly that the target CPU is 32 bit

[Paul Brook]

On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> On Fri, Nov 30, 2007 at 04:28:09PM +0000, Paul Brook wrote:
> > On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> > > 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

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

Re: [Qemu-devel] [PATCH] sh4: define explicitly that the target CPU is 32 bit

[Blue Swirl]

On 11/30/07, Paul Brook <paul@codesourcery.com> wrote:
> On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> > On Fri, Nov 30, 2007 at 04:28:09PM +0000, Paul Brook wrote:
> > > On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> > > > 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
>
> 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.

Re: [Qemu-devel] [PATCH] sh4: define explicitly that the target CPU is 32 bit

[Paul Mundt]

On Fri, Nov 30, 2007 at 05:15:21PM +0000, Paul Brook wrote:
> On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> > 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
> 
> 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.