[Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

This patch removes the restriction of 2G ram size on 64-bit hosts.
Theoretically Sparc32 on a SS-10 like machine could handle more than
62GB of memory.

There seems to be problems in the boot BIOSes to manage even >2G
memory sizes, I've found some in OpenBIOS but there are still many
left.

Any comments?

[-- Attachment #2: more_mem.diff --]
[-- Type: text/x-diff, Size: 7414 bytes --]

Index: qemu/exec.c
===================================================================
--- qemu.orig/exec.c	2007-06-25 14:50:03.000000000 +0000
+++ qemu/exec.c	2007-06-25 14:50:40.000000000 +0000
@@ -86,7 +86,7 @@
 uint8_t code_gen_buffer[CODE_GEN_BUFFER_SIZE] __attribute__((aligned (32)));
 uint8_t *code_gen_ptr;
 
-int phys_ram_size;
+unsigned long phys_ram_size;
 int phys_ram_fd;
 uint8_t *phys_ram_base;
 uint8_t *phys_ram_dirty;
@@ -111,7 +111,7 @@
 
 typedef struct PhysPageDesc {
     /* offset in host memory of the page + io_index in the low 12 bits */
-    uint32_t phys_offset;
+    unsigned long phys_offset;
 } PhysPageDesc;
 
 #define L2_BITS 10
@@ -1913,7 +1913,7 @@
 
 static int subpage_register (subpage_t *mmio, uint32_t start, uint32_t end,
                              int memory);
-static void *subpage_init (target_phys_addr_t base, uint32_t *phys,
+static void *subpage_init (target_phys_addr_t base, unsigned long *phys,
                            int orig_memory);
 #define CHECK_SUBPAGE(addr, start_addr, start_addr2, end_addr, end_addr2, \
                       need_subpage)                                     \
@@ -2358,7 +2358,7 @@
     return 0;
 }
 
-static void *subpage_init (target_phys_addr_t base, uint32_t *phys,
+static void *subpage_init (target_phys_addr_t base, unsigned long *phys,
                            int orig_memory)
 {
     subpage_t *mmio;
Index: qemu/vl.c
===================================================================
--- qemu.orig/vl.c	2007-06-25 14:50:03.000000000 +0000
+++ qemu/vl.c	2007-06-25 14:50:40.000000000 +0000
@@ -116,7 +116,11 @@
 //#define DEBUG_UNUSED_IOPORT
 //#define DEBUG_IOPORT
 
+#if HOST_LONG_BITS < 64
 #define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024)
+#else
+#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)
+#endif
 
 #ifdef TARGET_PPC
 #define DEFAULT_RAM_SIZE 144
@@ -151,7 +155,7 @@
 const char* keyboard_layout = NULL;
 int64_t ticks_per_sec;
 int boot_device = 'c';
-int ram_size;
+unsigned long ram_size;
 int pit_min_timer_count = 0;
 int nb_nics;
 NICInfo nd_table[MAX_NICS];
@@ -7453,7 +7457,7 @@
                 help();
                 break;
             case QEMU_OPTION_m:
-                ram_size = atoi(optarg) * 1024 * 1024;
+                ram_size = (unsigned long)atoi(optarg) * 1024 * 1024;
                 if (ram_size <= 0)
                     help();
                 if (ram_size > PHYS_RAM_MAX_SIZE) {
Index: qemu/vl.h
===================================================================
--- qemu.orig/vl.h	2007-06-25 14:50:03.000000000 +0000
+++ qemu/vl.h	2007-06-25 14:50:40.000000000 +0000
@@ -145,7 +145,7 @@
 
 void main_loop_wait(int timeout);
 
-extern int ram_size;
+extern unsigned long ram_size;
 extern int bios_size;
 extern int rtc_utc;
 extern int cirrus_vga_enabled;
@@ -705,7 +705,7 @@
 
 #ifndef QEMU_TOOL
 
-typedef void QEMUMachineInitFunc(int ram_size, int vga_ram_size, 
+typedef void QEMUMachineInitFunc(unsigned long ram_size, int vga_ram_size,
                                  int boot_device,
              DisplayState *ds, const char **fd_filename, int snapshot,
              const char *kernel_filename, const char *kernel_cmdline,
Index: qemu/hw/sun4m.c
===================================================================
--- qemu.orig/hw/sun4m.c	2007-06-25 14:50:36.000000000 +0000
+++ qemu/hw/sun4m.c	2007-06-25 16:16:43.000000000 +0000
@@ -290,7 +290,7 @@
     env->halted = 1;
 }
 
-static void *sun4m_hw_init(const struct hwdef *hwdef, int RAM_size,
+static void *sun4m_hw_init(const struct hwdef *hwdef, unsigned long RAM_size,
                            DisplayState *ds, const char *cpu_model)
 
 {
@@ -390,7 +390,8 @@
     return nvram;
 }
 
-static void sun4m_load_kernel(long vram_size, int RAM_size, int boot_device,
+static void sun4m_load_kernel(long vram_size, unsigned long RAM_size,
+                              int boot_device,
                               const char *kernel_filename,
                               const char *kernel_cmdline,
                               const char *initrd_filename,
@@ -525,17 +526,20 @@
     },
 };
 
-static void sun4m_common_init(int RAM_size, int boot_device, DisplayState *ds,
-                              const char *kernel_filename, const char *kernel_cmdline,
-                              const char *initrd_filename, const char *cpu_model,
-                              unsigned int machine, int max_ram)
+static void sun4m_common_init(unsigned long RAM_size, int boot_device,
+                              DisplayState *ds,
+                              const char *kernel_filename,
+                              const char *kernel_cmdline,
+                              const char *initrd_filename,
+                              const char *cpu_model,
+                              unsigned int machine, unsigned long max_ram)
 {
     void *nvram;
 
-    if ((unsigned int)RAM_size > (unsigned int)max_ram) {
-        fprintf(stderr, "qemu: Too much memory for this machine: %d, maximum %d\n",
-                (unsigned int)RAM_size / (1024 * 1024),
-                (unsigned int)max_ram / (1024 * 1024));
+    if (RAM_size > max_ram) {
+        fprintf(stderr, "qemu: Too much memory for this machine: %ld, maximum %ld\n",
+                RAM_size / (1024 * 1024),
+                max_ram / (1024 * 1024));
         exit(1);
     }
     nvram = sun4m_hw_init(&hwdefs[machine], RAM_size, ds, cpu_model);
@@ -546,10 +550,10 @@
 }
 
 /* SPARCstation 5 hardware initialisation */
-static void ss5_init(int RAM_size, int vga_ram_size, int boot_device,
-                       DisplayState *ds, const char **fd_filename, int snapshot,
-                       const char *kernel_filename, const char *kernel_cmdline,
-                       const char *initrd_filename, const char *cpu_model)
+static void ss5_init(unsigned long RAM_size, int vga_ram_size, int boot_device,
+                     DisplayState *ds, const char **fd_filename, int snapshot,
+                     const char *kernel_filename, const char *kernel_cmdline,
+                     const char *initrd_filename, const char *cpu_model)
 {
     if (cpu_model == NULL)
         cpu_model = "Fujitsu MB86904";
@@ -559,10 +563,10 @@
 }
 
 /* SPARCstation 10 hardware initialisation */
-static void ss10_init(int RAM_size, int vga_ram_size, int boot_device,
-                            DisplayState *ds, const char **fd_filename, int snapshot,
-                            const char *kernel_filename, const char *kernel_cmdline,
-                            const char *initrd_filename, const char *cpu_model)
+static void ss10_init(unsigned long RAM_size, int vga_ram_size, int boot_device,
+                      DisplayState *ds, const char **fd_filename, int snapshot,
+                      const char *kernel_filename, const char *kernel_cmdline,
+                      const char *initrd_filename, const char *cpu_model)
 {
     if (cpu_model == NULL)
         cpu_model = "TI SuperSparc II";
Index: qemu/cpu-all.h
===================================================================
--- qemu.orig/cpu-all.h	2007-06-25 14:50:03.000000000 +0000
+++ qemu/cpu-all.h	2007-06-25 14:50:40.000000000 +0000
@@ -769,7 +769,7 @@
 
 /* memory API */
 
-extern int phys_ram_size;
+extern unsigned long phys_ram_size;
 extern int phys_ram_fd;
 extern uint8_t *phys_ram_base;
 extern uint8_t *phys_ram_dirty;

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Michal Schulz]

On Monday 25 June 2007, Blue Swirl wrote:
> This patch removes the restriction of 2G ram size on 64-bit hosts.
> Theoretically Sparc32 on a SS-10 like machine could handle more than
> 62GB of memory.
>
> There seems to be problems in the boot BIOSes to manage even >2G
> memory sizes, I've found some in OpenBIOS but there are still many
> left.
>
> Any comments?

One from me, if you like... Just don't use the "unsigned long" type. The 
intptr_t type would be better (it's 32-bit on 32-bit systems and 64-bit on 
64-bit systems).

My 0,02€.

-- 
Michal Schulz

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Blue Swirl]

On 6/25/07, Michal Schulz <michal.schulz@gmx.de> wrote:
> On Monday 25 June 2007, Blue Swirl wrote:
> > This patch removes the restriction of 2G ram size on 64-bit hosts.
> > Theoretically Sparc32 on a SS-10 like machine could handle more than
> > 62GB of memory.
> >
> > There seems to be problems in the boot BIOSes to manage even >2G
> > memory sizes, I've found some in OpenBIOS but there are still many
> > left.
> >
> > Any comments?
>
> One from me, if you like... Just don't use the "unsigned long" type. The
> intptr_t type would be better (it's 32-bit on 32-bit systems and 64-bit on
> 64-bit systems).

Nice, I didn't know about that. But how is this any different from
unsigned long?

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Michal Schulz]

On Monday 25 June 2007, Blue Swirl wrote:

> Nice, I didn't know about that. But how is this any different from
> unsigned long?

It may be the same. But at least the code looks more consistent (IMHO) :)

-- 
Michal Schulz

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Karl Magdsick]

Depends on if you're using the LP64 model (64-bit Linux, many other
*NIX) or the LLP64 model (Win64).

I guess Microsoft decided there was more code written for their system
that assumed longs were 32-bit than code that assumed pointers could
be stored in (unsigned) longs.  For 64-bit  MS Windows code, pointers
are 64-bit, longs are 32-bit, and long longs are 64-bit.

With proper support from the compiler, it's theoretically possible on
x86-64 systems to use 32-bit pointers in long mode (16 general purpose
64-bit registers).  (There's an instruction prefix that will cause the
CPU to perform 32-bit pointer calculations in the 64-bit address
space.) I'm not aware of any systems that use this, however.  (Getting
the speed boost from fewer register spills while not paying the space
cost of 64-bit pointers sounds very attractive in many applications,
though.)  I'm not sure if any of the C standards forbid longs being
larger than pointers.

There are even more strange beasts out there.  I think IBM AS/400 LIC
uses 128-bit pointers.  (The LIC code gets compiled to native code and
appended to the LIC binary the first time the LIC binary is run on a
new system, and IBM decided to build a lot of future compatibility
into LIC.)  I'm not sure how big longs are on those systems, but I
wouldn't be surprised if longs are 32-bits or 64-bits and pointers
128-bits.

In any case, I'm a big fan of using more descriptive types (such as
the C99 types) to express yourself more clearly for both the compiler
and for other coders.


Cheers,
-Karl

On 6/25/07, Blue Swirl <blauwirbel@gmail.com> wrote:
> On 6/25/07, Michal Schulz <michal.schulz@gmx.de> wrote:
[snip]
> > One from me, if you like... Just don't use the "unsigned long" type. The
> > intptr_t type would be better (it's 32-bit on 32-bit systems and 64-bit on
> > 64-bit systems).
>
> Nice, I didn't know about that. But how is this any different from
> unsigned long?

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Thiemo Seufer]

Karl Magdsick wrote:
[snip]
> With proper support from the compiler, it's theoretically possible on
> x86-64 systems to use 32-bit pointers in long mode (16 general purpose
> 64-bit registers).  (There's an instruction prefix that will cause the
> CPU to perform 32-bit pointer calculations in the 64-bit address
> space.) I'm not aware of any systems that use this, however.  (Getting
> the speed boost from fewer register spills while not paying the space
> cost of 64-bit pointers sounds very attractive in many applications,
> though.)

FYI, the MIPS N32 ABI does that (64bit wide registers, 32bit address
space, data type sizes compatible to pure 32bit programs).


Thiemo

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Paul Brook]

> With proper support from the compiler, it's theoretically possible on
> x86-64 systems to use 32-bit pointers in long mode. I'm not aware of any 
systems that use this, however.

Vxworks does. We just finished doing the gcc port. From a software point of 
view ILP32 mode on a 64-bit CPU/OS is indistinguishable from regular 32-bit 
mode.
>  I'm not sure how big longs are on those systems, but I
> wouldn't be surprised if longs are 32-bits or 64-bits and pointers
> 128-bits.

I really hope not.

> > > One from me, if you like... Just don't use the "unsigned long" type.
> > > The intptr_t type would be better (it's 32-bit on 32-bit systems and
> > > 64-bit on 64-bit systems).
> >
> > Nice, I didn't know about that. But how is this any different from
> > unsigned long?

The story behind this is that ISO C89 requires that "long" be at least as big 
as a pointer (ie. "void *"). The actual requirement is that it be possible to 
store a pointer in a standard integer type, and "long" is the largest 
standard integer type.

Unfortunately C99 relaxed this requirement, and allowed abominations like the 
win64 ABI.

This means you have a choice: Write standard conforming code (long) that works 
on all known systems except win64, or use features that do't exist on many 
systems. IIRC C99 types like intptr_t are not supported on several fairly 
common unix systems.

It's ironic that the one system that requires C99 features explicitly does not 
(and probably never will) have full C99 support.

Paul

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Blue Swirl]

On 6/26/07, Paul Brook <paul@codesourcery.com> wrote:
> The story behind this is that ISO C89 requires that "long" be at least as big
> as a pointer (ie. "void *"). The actual requirement is that it be possible to
> store a pointer in a standard integer type, and "long" is the largest
> standard integer type.
>
> Unfortunately C99 relaxed this requirement, and allowed abominations like the
> win64 ABI.
>
> This means you have a choice: Write standard conforming code (long) that works
> on all known systems except win64, or use features that do't exist on many
> systems. IIRC C99 types like intptr_t are not supported on several fairly
> common unix systems.

In that case I'll vote for unsigned long. I'd pass the issue to those
doing a win64 port, if ever that happens.

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Julian Seward]

> > Unfortunately C99 relaxed this requirement, and allowed abominations like
> > the win64 ABI.
> >
> > This means you have a choice: Write standard conforming code (long) that
> > works on all known systems except win64, or use features that do't exist
> > on many systems. IIRC C99 types like intptr_t are not supported on
> > several fairly common unix systems.
>
> In that case I'll vote for unsigned long. I'd pass the issue to those
> doing a win64 port, if ever that happens.

In Valgrind-world we use an alternative approach, which is to typedef
a set of new integral types and use those exclusively, and not use the
native 'int', 'long' etc.  The new types have a single fixed meaning
regardless of the host or guest and it is up to the configure script
to set up suitable typedefs.  At startup Valgrind checks the size and
signedness of these types is as expected, so any configuration errors
are caught.  This has proved very helpful in porting to a number of 
platforms.

J

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Thiemo Seufer]

Julian Seward wrote:
> 
> > > Unfortunately C99 relaxed this requirement, and allowed abominations like
> > > the win64 ABI.
> > >
> > > This means you have a choice: Write standard conforming code (long) that
> > > works on all known systems except win64, or use features that do't exist
> > > on many systems. IIRC C99 types like intptr_t are not supported on
> > > several fairly common unix systems.
> >
> > In that case I'll vote for unsigned long. I'd pass the issue to those
> > doing a win64 port, if ever that happens.
> 
> In Valgrind-world we use an alternative approach, which is to typedef
> a set of new integral types and use those exclusively, and not use the
> native 'int', 'long' etc.  The new types have a single fixed meaning
> regardless of the host or guest and it is up to the configure script
> to set up suitable typedefs.  At startup Valgrind checks the size and
> signedness of these types is as expected, so any configuration errors
> are caught.  This has proved very helpful in porting to a number of 
> platforms.

FWIW, I agree with that.


Thiemo

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Julian Seward]

> > > > This means you have a choice: Write standard conforming code (long)
> > > > that works on all known systems except win64, or use features that
> > > > do't exist on many systems. IIRC C99 types like intptr_t are not
> > > > supported on several fairly common unix systems.
> > >
> > > In that case I'll vote for unsigned long. I'd pass the issue to those
> > > doing a win64 port, if ever that happens.
> >
> > In Valgrind-world we use an alternative approach, which is to typedef
> > a set of new integral types and use those exclusively, and not use the
> > native 'int', 'long' etc.  The new types have a single fixed meaning
> > regardless of the host or guest and it is up to the configure script
> > to set up suitable typedefs.  At startup Valgrind checks the size and
> > signedness of these types is as expected, so any configuration errors
> > are caught.  This has proved very helpful in porting to a number of
> > platforms.

So in this particular case we have the types UWord and Word 
(unsigned and signed machine words) which it is guaranteed are
the same size as void*, on all platforms.

We also capitalise the first letter of all type names as that
makes the code easier to read and makes it obvious when you are
inadvertantly using the native 'int', 'long' etc.

J

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Marius Groeger]

On Wed, 27 Jun 2007, Julian Seward wrote:

> > > In Valgrind-world we use an alternative approach, which is to typedef
> > > a set of new integral types and use those exclusively, and not use the
> > > native 'int', 'long' etc.  The new types have a single fixed meaning
> > > regardless of the host or guest and it is up to the configure script
> > > to set up suitable typedefs.  At startup Valgrind checks the size and
> > > signedness of these types is as expected, so any configuration errors
> > > are caught.  This has proved very helpful in porting to a number of
> > > platforms.
> 
> So in this particular case we have the types UWord and Word 
> (unsigned and signed machine words) which it is guaranteed are
> the same size as void*, on all platforms.
> 
> We also capitalise the first letter of all type names as that
> makes the code easier to read and makes it obvious when you are
> inadvertantly using the native 'int', 'long' etc.

FWIW, any C code defining such types with a "single fixed meaning" 
should use very(!) distinct prefixes to keep those identifiers within 
their own namespace. From what I can tell having done quite a lot of 
porting and component integration of C code, capitalization is 
definitely not enough to ensure self-containedness of your code. :-)

Regards
Marius

-- 
Marius Groeger <mgroeger@sysgo.com>
SYSGO AG                      Embedded and Real-Time Software
Voice: +49 6136 9948 0                  FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com

Handelsregister: HRB Mainz 90 HRB 8066
Vorstand: Knut Degen, Robert Kaiser, Detlev Schaadt
Aufsichtsratsvorsitzender: Dr. Thomas Hoch
USt(VAT)-Id-Nr.: DE 149062328

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Thiemo Seufer]

Marius Groeger wrote:
> On Wed, 27 Jun 2007, Julian Seward wrote:
> 
> > > > In Valgrind-world we use an alternative approach, which is to typedef
> > > > a set of new integral types and use those exclusively, and not use the
> > > > native 'int', 'long' etc.  The new types have a single fixed meaning
> > > > regardless of the host or guest and it is up to the configure script
> > > > to set up suitable typedefs.  At startup Valgrind checks the size and
> > > > signedness of these types is as expected, so any configuration errors
> > > > are caught.  This has proved very helpful in porting to a number of
> > > > platforms.
> > 
> > So in this particular case we have the types UWord and Word 
> > (unsigned and signed machine words) which it is guaranteed are
> > the same size as void*, on all platforms.
> > 
> > We also capitalise the first letter of all type names as that
> > makes the code easier to read and makes it obvious when you are
> > inadvertantly using the native 'int', 'long' etc.
> 
> FWIW, any C code defining such types with a "single fixed meaning" 
> should use very(!) distinct prefixes to keep those identifiers within 
> their own namespace. From what I can tell having done quite a lot of 
> porting and component integration of C code, capitalization is 
> definitely not enough to ensure self-containedness of your code. :-)

Indeed. We have already host_ and target_ prefixes in some places, which
are IMHO a natural choice for a naming convention.


Thiemo

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Rob Landley]

On Wednesday 27 June 2007 06:26:54 Blue Swirl wrote:
> On 6/26/07, Paul Brook <paul@codesourcery.com> wrote:
> > The story behind this is that ISO C89 requires that "long" be at least as
> > big as a pointer (ie. "void *"). The actual requirement is that it be
> > possible to store a pointer in a standard integer type, and "long" is the
> > largest standard integer type.
> >
> > Unfortunately C99 relaxed this requirement, and allowed abominations like
> > the win64 ABI.
> >
> > This means you have a choice: Write standard conforming code (long) that
> > works on all known systems except win64, or use features that do't exist
> > on many systems. IIRC C99 types like intptr_t are not supported on
> > several fairly common unix systems.
>
> In that case I'll vote for unsigned long. I'd pass the issue to those
> doing a win64 port, if ever that happens.

The actual standards documents on this, by the way, are at:

The LP64 standard: http://www.unix.org/whitepapers/64bit.html
The LP64 rationale: http://www.unix.org/version2/whatsnew/lp64_wp.html

Upshot: on any Linux, char is 8 bits, short is 16, int is 32, and long is 32 
on 32-bit and 64 on 64-bit.  And you can rely on that.

Linux supports this standard on all target platforms.  As do MacOS X and the 
BSDs.

Windows doesn't actually have standards, but their rationale for LLP64 (a term 
they made up) was explained in a blog post from one of the developers: 
http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx

I'm unaware of anyone actually successfully deploying Win64 for anything (I 
know of a few test deployments, but they failed and were withdrawn), so the 
Win64 API being broken and unusable is largely an academic question. This 
doesn't affect Win32, which is what well over 99% of the Windows installed 
base uses.

Beyond that, C99 gives you int8_t through int64_t (and corresponding uint64_t 
types) that are also guaranteed sizes, and that part even works on Windows 
(as much as anything does).

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Gwenole Beauchesne]

Hi,

2007/6/26, Karl Magdsick <kmagnum@gmail.com>:

> With proper support from the compiler, it's theoretically possible on
> x86-64 systems to use 32-bit pointers in long mode (16 general purpose
> 64-bit registers).  (There's an instruction prefix that will cause the
> CPU to perform 32-bit pointer calculations in the 64-bit address
> space.) I'm not aware of any systems that use this, however.

IIRC, there used to be an ILP32 programming model in long mode for
older AMD64 prototypes, i.e. with access to full 64-bit registers.
However, nobody was interested in it at that time so this was dropped.

There is still however, as you mention, an override prefix to do
32-bit pointer calculation (0x67). Please note documents around the
Intel Core processor mention a 5 cycle penalty when you use this
prefix. This doesn't seem to be a penalty for AMD processors though.
In practise, the impact on the generated code performance of my JIT
was measurably marginal (well, I only tested against my Core 2 and
Athlon 64 CPUs).

BTW, before I switched to using the address override prefix, I used to
implement a so-called 33-bit addressing mode in BasiliskII. That is,
the emulated address space is doubled to cope with the excess bits
during calculation. A shared segment is shm_open()'ed and then
mmap()'ed to BASE and BASE+(1L<<32).
-- 
Gwenolé

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Thiemo Seufer]

Blue Swirl wrote:
> This patch removes the restriction of 2G ram size on 64-bit hosts.
> Theoretically Sparc32 on a SS-10 like machine could handle more than
> 62GB of memory.
> 
> There seems to be problems in the boot BIOSes to manage even >2G
> memory sizes, I've found some in OpenBIOS but there are still many
> left.
> 
> Any comments?

Probably it's time for host_phys_addr_t instead of unsigned long, for
clarity and improved portability.


Thiemo

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

[Blue Swirl]

On 6/25/07, Thiemo Seufer <ths@networkno.de> wrote:
> Blue Swirl wrote:
> > This patch removes the restriction of 2G ram size on 64-bit hosts.
> > Theoretically Sparc32 on a SS-10 like machine could handle more than
> > 62GB of memory.
> >
> > There seems to be problems in the boot BIOSes to manage even >2G
> > memory sizes, I've found some in OpenBIOS but there are still many
> > left.
> >
> > Any comments?
>
> Probably it's time for host_phys_addr_t instead of unsigned long, for
> clarity and improved portability.

Good idea, I'll make a new patch using that.