| Message ID | 1310740376-13323-4-git-send-email-anthony.perard@citrix.com |
|---|---|
| State | New |
| Headers | show |
On 15.07.2011, at 16:32, Anthony Perard wrote: > In Xen case, memory can be bigger than the host memory. that mean a > 32bits host (and QEMU) should be able to handle a RAM address of 64bits. > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > --- > cpu-common.h | 8 ++++++++ > exec.c | 9 +++++---- > xen-all.c | 2 +- > 3 files changed, 14 insertions(+), 5 deletions(-) > > diff --git a/cpu-common.h b/cpu-common.h > index e4fcded..e1b40fe 100644 > --- a/cpu-common.h > +++ b/cpu-common.h > @@ -27,7 +27,15 @@ enum device_endian { > }; > > /* address in the RAM (different from a physical address) */ > +#ifndef CONFIG_XEN_BACKEND > typedef unsigned long ram_addr_t; Do we really want to depend this on _BACKEND? ram_addr_t is target dependent, no? Alex
On Mon, Jul 18, 2011 at 13:30, Alexander Graf <agraf@suse.de> wrote: > > On 15.07.2011, at 16:32, Anthony Perard wrote: > >> In Xen case, memory can be bigger than the host memory. that mean a >> 32bits host (and QEMU) should be able to handle a RAM address of 64bits. >> >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> >> --- >> cpu-common.h | 8 ++++++++ >> exec.c | 9 +++++---- >> xen-all.c | 2 +- >> 3 files changed, 14 insertions(+), 5 deletions(-) >> >> diff --git a/cpu-common.h b/cpu-common.h >> index e4fcded..e1b40fe 100644 >> --- a/cpu-common.h >> +++ b/cpu-common.h >> @@ -27,7 +27,15 @@ enum device_endian { >> }; >> >> /* address in the RAM (different from a physical address) */ >> +#ifndef CONFIG_XEN_BACKEND >> typedef unsigned long ram_addr_t; > > Do we really want to depend this on _BACKEND? ram_addr_t is target dependent, no? :(, indeed, it's seams to be target dependent, I did not check that carefully enough. So CONFIG_XEN is enough. Thanks,
On Mon, Jul 18, 2011 at 15:46, Anthony PERARD <anthony.perard@citrix.com> wrote: > On Mon, Jul 18, 2011 at 13:30, Alexander Graf <agraf@suse.de> wrote: >> >> On 15.07.2011, at 16:32, Anthony Perard wrote: >> >>> In Xen case, memory can be bigger than the host memory. that mean a >>> 32bits host (and QEMU) should be able to handle a RAM address of 64bits. >>> >>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> >>> --- >>> cpu-common.h | 8 ++++++++ >>> exec.c | 9 +++++---- >>> xen-all.c | 2 +- >>> 3 files changed, 14 insertions(+), 5 deletions(-) >>> >>> diff --git a/cpu-common.h b/cpu-common.h >>> index e4fcded..e1b40fe 100644 >>> --- a/cpu-common.h >>> +++ b/cpu-common.h >>> @@ -27,7 +27,15 @@ enum device_endian { >>> }; >>> >>> /* address in the RAM (different from a physical address) */ >>> +#ifndef CONFIG_XEN_BACKEND >>> typedef unsigned long ram_addr_t; >> >> Do we really want to depend this on _BACKEND? ram_addr_t is target dependent, no? > > :(, indeed, it's seams to be target dependent, I did not check that > carefully enough. So CONFIG_XEN is enough. Actually, this does not work because it is used in libhw64 (like target_phys_addr_t). So I am thinking about eithier introduce a new config variable in ./configure (ram_addr_bits), or just have #if defined(CONFIG_XEN_BACKEND) && TARGET_PHYS_ADDR_BITS == 64 So, libhw64 with xen activated will be compiled with a ram_addr of 64b, and the libhw32 will stay with a "unsigned long".
diff --git a/cpu-common.h b/cpu-common.h index e4fcded..e1b40fe 100644 --- a/cpu-common.h +++ b/cpu-common.h @@ -27,7 +27,15 @@ enum device_endian { }; /* address in the RAM (different from a physical address) */ +#ifndef CONFIG_XEN_BACKEND typedef unsigned long ram_addr_t; +# define RAM_ADDR_MAX ULONG_MAX +# define RAM_ADDR_FMT "%lx" +#else +typedef uint64_t ram_addr_t; +# define RAM_ADDR_MAX UINT64_MAX +# define RAM_ADDR_FMT "%" PRIx64 +#endif /* memory API */ diff --git a/exec.c b/exec.c index 4220d45..b671cfd 100644 --- a/exec.c +++ b/exec.c @@ -2863,13 +2863,13 @@ static void *file_ram_alloc(RAMBlock *block, static ram_addr_t find_ram_offset(ram_addr_t size) { RAMBlock *block, *next_block; - ram_addr_t offset = 0, mingap = ULONG_MAX; + ram_addr_t offset = 0, mingap = RAM_ADDR_MAX; if (QLIST_EMPTY(&ram_list.blocks)) return 0; QLIST_FOREACH(block, &ram_list.blocks, next) { - ram_addr_t end, next = ULONG_MAX; + ram_addr_t end, next = RAM_ADDR_MAX; end = block->offset + block->length; @@ -3081,7 +3081,8 @@ void qemu_ram_remap(ram_addr_t addr, ram_addr_t length) #endif } if (area != vaddr) { - fprintf(stderr, "Could not remap addr: %lx@%lx\n", + fprintf(stderr, "Could not remap addr: " + RAM_ADDR_FMT "@" RAM_ADDR_FMT "\n", length, addr); exit(1); } @@ -4052,7 +4053,7 @@ void *cpu_physical_memory_map(target_phys_addr_t addr, target_phys_addr_t page; unsigned long pd; PhysPageDesc *p; - ram_addr_t raddr = ULONG_MAX; + ram_addr_t raddr = RAM_ADDR_MAX; ram_addr_t rlen; void *ret; diff --git a/xen-all.c b/xen-all.c index 8105c83..2c0a62d 100644 --- a/xen-all.c +++ b/xen-all.c @@ -184,7 +184,7 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size) } if (xc_domain_populate_physmap_exact(xen_xc, xen_domid, nr_pfn, 0, 0, pfn_list)) { - hw_error("xen: failed to populate ram at %lx", ram_addr); + hw_error("xen: failed to populate ram at " RAM_ADDR_FMT, ram_addr); } qemu_free(pfn_list);
In Xen case, memory can be bigger than the host memory. that mean a 32bits host (and QEMU) should be able to handle a RAM address of 64bits. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- cpu-common.h | 8 ++++++++ exec.c | 9 +++++---- xen-all.c | 2 +- 3 files changed, 14 insertions(+), 5 deletions(-)