thr3ads.net - Xen devel - [Xen-devel] [PATCH 0/5] Enable QEMU to handle more than 2GB with Xen. [Jul 2011]

If this information is useful, please help other people find it:
Share via:

Anthony PERARD

2011-Jul-15 14:32 UTC

[Xen-devel] [PATCH 0/5] Enable QEMU to handle more than 2GB with Xen.

Hi all,

Xen is not limited by the QEMU''s virtual address space for the
allocation of
the guest RAM. So even with a QEMU 32bits, a Xen guest can have more than 4 GB
of RAM.

With this serie, we will be able to run a guest with more than 4GB. The main
point is to change ram_addr_t from ulong to uin64 when QEMU is configure with
Xen. The second point is better register the memory in QEMU.

Regards,


Anthony PERARD (5):
  xen: Fix xen_enabled().
  exec.c: Use ram_addr_t in cpu_physical_memory_rw(...).
  cpu-common: Have a ram_addr_t of uint64 with Xen.
  xen: Fix the memory registration to reflect of what is done by Xen.
  vl.c: Check the asked ram_size later.

 cpu-common.h |    8 ++++++++
 exec.c       |   13 +++++++------
 hw/xen.h     |    2 +-
 vl.c         |   14 ++++++++------
 xen-all.c    |   23 +++++++++++++++--------
 5 files changed, 39 insertions(+), 21 deletions(-)

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Anthony PERARD

2011-Jul-15 14:32 UTC

head link

[Xen-devel] [PATCH 1/5] xen: Fix xen_enabled().

Use the "host" CONFIG_ define instead of the "target" one.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/xen.h b/hw/xen.h
index e432705..43b95d6 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -24,7 +24,7 @@ extern int xen_allowed;
 
 static inline int xen_enabled(void)
 {
-#ifdef CONFIG_XEN
+#ifdef CONFIG_XEN_BACKEND
     return xen_allowed;
 #else
     return 0;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Anthony PERARD

2011-Jul-15 14:32 UTC

head link

[Xen-devel] [PATCH 2/5] exec.c: Use ram_addr_t in cpu_physical_memory_rw(...).

As the variable pd and addr1 inside the function cpu_physical_memory_rw
are mean to handle a RAM address, they should be of the ram_addr_t type
instead of unsigned long.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 exec.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/exec.c b/exec.c
index c0673c2..4220d45 100644
--- a/exec.c
+++ b/exec.c
@@ -3858,7 +3858,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr,
uint8_t *buf,
     uint8_t *ptr;
     uint32_t val;
     target_phys_addr_t page;
-    unsigned long pd;
+    ram_addr_t pd;
     PhysPageDesc *p;
 
     while (len > 0) {
@@ -3898,7 +3898,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr,
uint8_t *buf,
                     l = 1;
                 }
             } else {
-                unsigned long addr1;
+                ram_addr_t addr1;
                 addr1 = (pd & TARGET_PAGE_MASK) + (addr &
~TARGET_PAGE_MASK);
                 /* RAM case */
                 ptr = qemu_get_ram_ptr(addr1);
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Anthony PERARD

2011-Jul-15 14:32 UTC

head link

[Xen-devel] [PATCH 3/5] cpu-common: Have a ram_addr_t of uint64 with Xen.

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;
+#  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);
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Anthony PERARD

2011-Jul-15 14:32 UTC

head link

[Xen-devel] [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.

A Xen guest memory is allocated by libxc. But this memory is not
allocated continuously, instead, it leaves the VGA IO memory space not
allocated, same for the MMIO space (at HVM_BELOW_4G_MMIO_START of size
HVM_BELOW_4G_MMIO_LENGTH).

So to reflect that, we do not register the physical memory for this two
holes. But we still keep only one RAMBlock for the all RAM as it is more
easier than have two separate blocks (1 above 4G). Also this prevent QEMU
from use the MMIO space for a ROM.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 xen-all.c |   21 ++++++++++++++-------
 1 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 2c0a62d..76d5c5c 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -144,6 +144,12 @@ static void xen_ram_init(ram_addr_t ram_size)
     new_block->host = NULL;
     new_block->offset = 0;
     new_block->length = ram_size;
+    if (ram_size >= HVM_BELOW_4G_RAM_END) {
+        /* Xen does not allocate the memory continuously, and keep a hole at
+         * HVM_BELOW_4G_MMIO_START of HVM_BELOW_4G_MMIO_LENGTH
+         */
+        new_block->length += HVM_BELOW_4G_MMIO_LENGTH;
+    }
 
     QLIST_INSERT_HEAD(&ram_list.blocks, new_block, next);
 
@@ -152,20 +158,21 @@ static void xen_ram_init(ram_addr_t ram_size)
     memset(ram_list.phys_dirty + (new_block->offset >>
TARGET_PAGE_BITS),
            0xff, new_block->length >> TARGET_PAGE_BITS);
 
-    if (ram_size >= 0xe0000000 ) {
-        above_4g_mem_size = ram_size - 0xe0000000;
-        below_4g_mem_size = 0xe0000000;
+    if (ram_size >= HVM_BELOW_4G_RAM_END) {
+        above_4g_mem_size = ram_size - HVM_BELOW_4G_RAM_END;
+        below_4g_mem_size = HVM_BELOW_4G_RAM_END;
     } else {
         below_4g_mem_size = ram_size;
     }
 
-    cpu_register_physical_memory(0, below_4g_mem_size, new_block->offset);
-#if TARGET_PHYS_ADDR_BITS > 32
+    cpu_register_physical_memory(0, 0xa0000, 0);
+    /* Skip of the VGA IO memory space */
+    cpu_register_physical_memory(0xc0000, below_4g_mem_size - 0xc0000,
+                                 0xc0000);
     if (above_4g_mem_size > 0) {
         cpu_register_physical_memory(0x100000000ULL, above_4g_mem_size,
-                                     new_block->offset + below_4g_mem_size);
+                                     0x100000000ULL);
     }
-#endif
 }
 
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size)
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Anthony PERARD

2011-Jul-15 14:32 UTC

head link

[Xen-devel] [PATCH 5/5] vl.c: Check the asked ram_size later.

As a Xen guest can have more than 2GB of RAM on a 32bit host, we move
the conditions after than we now if we run one Xen or not.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 vl.c |   14 ++++++++------
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/vl.c b/vl.c
index fcd7395..c2efedf 100644
--- a/vl.c
+++ b/vl.c
@@ -2433,11 +2433,6 @@ int main(int argc, char **argv, char **envp)
                     exit(1);
                 }
 
-                /* On 32-bit hosts, QEMU is limited by virtual address space */
-                if (value > (2047 << 20) && HOST_LONG_BITS ==
32) {
-                    fprintf(stderr, "qemu: at most 2047 MB RAM can be
simulated\n");
-                    exit(1);
-                }
                 if (value != (uint64_t)(ram_addr_t)value) {
                     fprintf(stderr, "qemu: ram size too large\n");
                     exit(1);
@@ -3091,8 +3086,15 @@ int main(int argc, char **argv, char **envp)
         exit(1);
 
     /* init the memory */
-    if (ram_size == 0)
+    if (ram_size == 0) {
         ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
+    } else if (!xen_enabled()) {
+        /* On 32-bit hosts, QEMU is limited by virtual address space */
+        if (ram_size > (2047 << 20) && HOST_LONG_BITS == 32) {
+            fprintf(stderr, "qemu: at most 2047 MB RAM can be
simulated\n");
+            exit(1);
+        }
+    }
 
     /* init the dynamic translator */
     cpu_exec_init_all(tb_size * 1024 * 1024);
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Paolo Bonzini

2011-Jul-15 14:46 UTC

head link

[Xen-devel] Re: [PATCH 2/5] exec.c: Use ram_addr_t in cpu_physical_memory_rw(...).

On 07/15/2011 04:32 PM, Anthony PERARD wrote:> As the variable pd and addr1 inside the function cpu_physical_memory_rw
> are mean to handle a RAM address, they should be of the ram_addr_t type
> instead of unsigned long.
>
> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
> ---
>   exec.c |    4 ++--
>   1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/exec.c b/exec.c
> index c0673c2..4220d45 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -3858,7 +3858,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr,
uint8_t *buf,
>       uint8_t *ptr;
>       uint32_t val;
>       target_phys_addr_t page;
> -    unsigned long pd;
> +    ram_addr_t pd;
>       PhysPageDesc *p;
>
>       while (len>  0) {
> @@ -3898,7 +3898,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr,
uint8_t *buf,
>                       l = 1;
>                   }
>               } else {
> -                unsigned long addr1;
> +                ram_addr_t addr1;
>                   addr1 = (pd&  TARGET_PAGE_MASK) + (addr& 
~TARGET_PAGE_MASK);
>                   /* RAM case */
>                   ptr = qemu_get_ram_ptr(addr1);
Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Paolo Bonzini

2011-Jul-15 14:46 UTC

head link

[Xen-devel] Re: [PATCH 1/5] xen: Fix xen_enabled().

On 07/15/2011 04:32 PM, Anthony PERARD wrote:> Use the "host" CONFIG_ define instead of the "target"
one.
>
> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
> ---
>   hw/xen.h |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/hw/xen.h b/hw/xen.h
> index e432705..43b95d6 100644
> --- a/hw/xen.h
> +++ b/hw/xen.h
> @@ -24,7 +24,7 @@ extern int xen_allowed;
>
>   static inline int xen_enabled(void)
>   {
> -#ifdef CONFIG_XEN
> +#ifdef CONFIG_XEN_BACKEND
>       return xen_allowed;
>   #else
>       return 0;
Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Paolo Bonzini

2011-Jul-15 14:52 UTC

head link

[Xen-devel] Re: [PATCH 5/5] vl.c: Check the asked ram_size later.

On 07/15/2011 04:32 PM, Anthony PERARD wrote:> As a Xen guest can have more than 2GB of RAM on a 32bit host, we move
> the conditions after than we now if we run one Xen or not.
>
> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
> ---
>   vl.c |   14 ++++++++------
>   1 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index fcd7395..c2efedf 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -2433,11 +2433,6 @@ int main(int argc, char **argv, char **envp)
>                       exit(1);
>                   }
>
> -                /* On 32-bit hosts, QEMU is limited by virtual address
space */
> -                if (value>  (2047<<  20)&& 
HOST_LONG_BITS == 32) {
> -                    fprintf(stderr, "qemu: at most 2047 MB RAM can be
simulated\n");
> -                    exit(1);
> -                }
>                   if (value != (uint64_t)(ram_addr_t)value) {
>                       fprintf(stderr, "qemu: ram size too
large\n");
>                       exit(1);
> @@ -3091,8 +3086,15 @@ int main(int argc, char **argv, char **envp)
>           exit(1);
>
>       /* init the memory */
> -    if (ram_size == 0)
> +    if (ram_size == 0) {
>           ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
> +    } else if (!xen_enabled()) {
> +        /* On 32-bit hosts, QEMU is limited by virtual address space */
> +        if (ram_size>  (2047<<  20)&&  HOST_LONG_BITS ==
32) {
> +            fprintf(stderr, "qemu: at most 2047 MB RAM can be
simulated\n");
> +            exit(1);
> +        }
> +    }
>
>       /* init the dynamic translator */
>       cpu_exec_init_all(tb_size * 1024 * 1024);
Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Paolo Bonzini

2011-Jul-15 14:55 UTC

head link

[Xen-devel] Re: [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.

On 07/15/2011 04:32 PM, Anthony PERARD wrote:> A Xen guest memory is allocated by libxc. But this memory is not
> allocated continuously, instead, it leaves the VGA IO memory space not
> allocated, same for the MMIO space (at HVM_BELOW_4G_MMIO_START of size
> HVM_BELOW_4G_MMIO_LENGTH).
>
> So to reflect that, we do not register the physical memory for this two
> holes. But we still keep only one RAMBlock for the all RAM as it is more
> easier than have two separate blocks (1 above 4G). Also this prevent QEMU
> from use the MMIO space for a ROM.
>
> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
> ---
>   xen-all.c |   21 ++++++++++++++-------
>   1 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/xen-all.c b/xen-all.c
> index 2c0a62d..76d5c5c 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -144,6 +144,12 @@ static void xen_ram_init(ram_addr_t ram_size)
>       new_block->host = NULL;
>       new_block->offset = 0;
>       new_block->length = ram_size;
> +    if (ram_size>= HVM_BELOW_4G_RAM_END) {
> +        /* Xen does not allocate the memory continuously, and keep a hole
at
> +         * HVM_BELOW_4G_MMIO_START of HVM_BELOW_4G_MMIO_LENGTH
> +         */
> +        new_block->length += HVM_BELOW_4G_MMIO_LENGTH;
> +    }
>
>       QLIST_INSERT_HEAD(&ram_list.blocks, new_block, next);
>
> @@ -152,20 +158,21 @@ static void xen_ram_init(ram_addr_t ram_size)
>       memset(ram_list.phys_dirty + (new_block->offset>> 
TARGET_PAGE_BITS),
>              0xff, new_block->length>>  TARGET_PAGE_BITS);
>
> -    if (ram_size>= 0xe0000000 ) {
> -        above_4g_mem_size = ram_size - 0xe0000000;
> -        below_4g_mem_size = 0xe0000000;
> +    if (ram_size>= HVM_BELOW_4G_RAM_END) {
> +        above_4g_mem_size = ram_size - HVM_BELOW_4G_RAM_END;
> +        below_4g_mem_size = HVM_BELOW_4G_RAM_END;
>       } else {
>           below_4g_mem_size = ram_size;
>       }
>
> -    cpu_register_physical_memory(0, below_4g_mem_size,
new_block->offset);
> -#if TARGET_PHYS_ADDR_BITS>  32
> +    cpu_register_physical_memory(0, 0xa0000, 0);
> +    /* Skip of the VGA IO memory space */
> +    cpu_register_physical_memory(0xc0000, below_4g_mem_size - 0xc0000,
> +                                 0xc0000);
>       if (above_4g_mem_size>  0) {
>           cpu_register_physical_memory(0x100000000ULL, above_4g_mem_size,
> -                                     new_block->offset +
below_4g_mem_size);
> +                                     0x100000000ULL);
>       }
> -#endif
>   }
>
>   void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size)
Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano Stabellini

2011-Jul-15 17:05 UTC

head link

[Xen-devel] Re: [PATCH 0/5] Enable QEMU to handle more than 2GB with Xen.

On Fri, 15 Jul 2011, Anthony PERARD wrote:> Hi all,
> 
> Xen is not limited by the QEMU''s virtual address space for the
allocation of
> the guest RAM. So even with a QEMU 32bits, a Xen guest can have more than 4
GB
> of RAM.
> 
> With this serie, we will be able to run a guest with more than 4GB. The
main
> point is to change ram_addr_t from ulong to uin64 when QEMU is configure
with
> Xen. The second point is better register the memory in QEMU.
> 
> Regards,
> 
> 
> Anthony PERARD (5):
>   xen: Fix xen_enabled().
>   exec.c: Use ram_addr_t in cpu_physical_memory_rw(...).
>   cpu-common: Have a ram_addr_t of uint64 with Xen.
>   xen: Fix the memory registration to reflect of what is done by Xen.
>   vl.c: Check the asked ram_size later.
> 
>  cpu-common.h |    8 ++++++++
>  exec.c       |   13 +++++++------
>  hw/xen.h     |    2 +-
>  vl.c         |   14 ++++++++------
>  xen-all.c    |   23 +++++++++++++++--------
>  5 files changed, 39 insertions(+), 21 deletions(-) 
All the patches look good to me, just a comment on the 4th patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano Stabellini

2011-Jul-15 17:05 UTC

head link

[Xen-devel] Re: [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.

On Fri, 15 Jul 2011, Anthony PERARD wrote:> A Xen guest memory is allocated by libxc. But this memory is not
> allocated continuously, instead, it leaves the VGA IO memory space not
> allocated, same for the MMIO space (at HVM_BELOW_4G_MMIO_START of size
> HVM_BELOW_4G_MMIO_LENGTH).
> 
> So to reflect that, we do not register the physical memory for this two
> holes. But we still keep only one RAMBlock for the all RAM as it is more
> easier than have two separate blocks (1 above 4G). Also this prevent QEMU
> from use the MMIO space for a ROM.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  xen-all.c |   21 ++++++++++++++-------
>  1 files changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/xen-all.c b/xen-all.c
> index 2c0a62d..76d5c5c 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -144,6 +144,12 @@ static void xen_ram_init(ram_addr_t ram_size)
>      new_block->host = NULL;
>      new_block->offset = 0;
>      new_block->length = ram_size;
> +    if (ram_size >= HVM_BELOW_4G_RAM_END) {
> +        /* Xen does not allocate the memory continuously, and keep a hole
at
> +         * HVM_BELOW_4G_MMIO_START of HVM_BELOW_4G_MMIO_LENGTH
> +         */
> +        new_block->length += HVM_BELOW_4G_MMIO_LENGTH;
> +    }
>  
>      QLIST_INSERT_HEAD(&ram_list.blocks, new_block, next);
>  
> @@ -152,20 +158,21 @@ static void xen_ram_init(ram_addr_t ram_size)
>      memset(ram_list.phys_dirty + (new_block->offset >>
TARGET_PAGE_BITS),
>             0xff, new_block->length >> TARGET_PAGE_BITS);
>  
> -    if (ram_size >= 0xe0000000 ) {
> -        above_4g_mem_size = ram_size - 0xe0000000;
> -        below_4g_mem_size = 0xe0000000;
> +    if (ram_size >= HVM_BELOW_4G_RAM_END) {
> +        above_4g_mem_size = ram_size - HVM_BELOW_4G_RAM_END;
> +        below_4g_mem_size = HVM_BELOW_4G_RAM_END;
>      } else {
>          below_4g_mem_size = ram_size;
>      }
>  
> -    cpu_register_physical_memory(0, below_4g_mem_size,
new_block->offset);
> -#if TARGET_PHYS_ADDR_BITS > 32
> +    cpu_register_physical_memory(0, 0xa0000, 0);
> +    /* Skip of the VGA IO memory space */
> +    cpu_register_physical_memory(0xc0000, below_4g_mem_size - 0xc0000,
> +                                 0xc0000); 
Shouldn''t we avoid registering any memory for the whole video ram area?
I mean:
    
0xa0000 - 0x100000



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Anthony PERARD

2011-Jul-15 17:51 UTC

head link

Re: [Xen-devel] Re: [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.

On Fri, Jul 15, 2011 at 18:05, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:> Shouldn''t we avoid registering any memory for the whole video ram
area?
> I mean:
>
> 0xa0000 - 0x100000
No, because SeaBIOS load the Options ROM (VGA Bios, PXE) to the area
between 0xc0000 and 0x100000, and this go through QEMU.

The area between 0xa0000 and 0xc0000 is registred later by the
cirrus_vga bits, as IO.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano Stabellini

2011-Jul-18 11:14 UTC

head link

Re: [Xen-devel] Re: [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.

On Fri, 15 Jul 2011, Anthony PERARD wrote:> On Fri, Jul 15, 2011 at 18:05, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > Shouldn''t we avoid registering any memory for the whole video
ram area?
> > I mean:
> >
> > 0xa0000 - 0x100000
> 
> No, because SeaBIOS load the Options ROM (VGA Bios, PXE) to the area
> between 0xc0000 and 0x100000, and this go through QEMU.
> 
> The area between 0xa0000 and 0xc0000 is registred later by the
> cirrus_vga bits, as IO.
OK. Can you please expand your comment in the code with the same
explanation?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Alexander Graf

2011-Jul-18 12:30 UTC

head link

[Xen-devel] Re: [PATCH 3/5] cpu-common: Have a ram_addr_t of uint64 with Xen.

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Alexander Graf

2011-Jul-18 12:32 UTC

head link

[Xen-devel] Re: [PATCH 0/5] Enable QEMU to handle more than 2GB with Xen.

On 15.07.2011, at 19:05, Stefano Stabellini wrote:
> On Fri, 15 Jul 2011, Anthony PERARD wrote:
>> Hi all,
>> 
>> Xen is not limited by the QEMU''s virtual address space for the
allocation of
>> the guest RAM. So even with a QEMU 32bits, a Xen guest can have more
than 4 GB
>> of RAM.
>> 
>> With this serie, we will be able to run a guest with more than 4GB. The
main
>> point is to change ram_addr_t from ulong to uin64 when QEMU is
configure with
>> Xen. The second point is better register the memory in QEMU.
>> 
>> Regards,
>> 
>> 
>> Anthony PERARD (5):
>>  xen: Fix xen_enabled().
>>  exec.c: Use ram_addr_t in cpu_physical_memory_rw(...).
>>  cpu-common: Have a ram_addr_t of uint64 with Xen.
>>  xen: Fix the memory registration to reflect of what is done by Xen.
>>  vl.c: Check the asked ram_size later.
>> 
>> cpu-common.h |    8 ++++++++
>> exec.c       |   13 +++++++------
>> hw/xen.h     |    2 +-
>> vl.c         |   14 ++++++++------
>> xen-all.c    |   23 +++++++++++++++--------
>> 5 files changed, 39 insertions(+), 21 deletions(-)
> 
> All the patches look good to me, just a comment on the 4th patch.
I included patches 1 and 2 in xen-next. 3 and 4 are in discussion and 5 should
only be applied when the others are in :)


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Alexander Graf

2011-Jul-18 12:43 UTC

head link

[Xen-devel] Re: [PATCH 1/5] xen: Fix xen_enabled().

On 15.07.2011, at 16:32, Anthony Perard wrote:
> Use the "host" CONFIG_ define instead of the "target"
one.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> hw/xen.h |    2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/hw/xen.h b/hw/xen.h
> index e432705..43b95d6 100644
> --- a/hw/xen.h
> +++ b/hw/xen.h
> @@ -24,7 +24,7 @@ extern int xen_allowed;
> 
> static inline int xen_enabled(void)
> {
> -#ifdef CONFIG_XEN
> +#ifdef CONFIG_XEN_BACKEND
is there any way to get this one more clever? The current patch fixes it for
your use case, sure, but I''d prefer that if you do:

  ./configure --enable-xen --target-list=alpha-softmmu

I''ll get xen_enabled to be inline exterminated and not slow down the
alpha target. How about something like

#ifdef CONFIG_NO_XEN
    return 0;
#elif defined(CONFIG_XEN_BACKEND)
    return xen_allowed;
#else
    return 0;
#endif

That way code that is compiled per-target won''t get slowed down just
because we have the xen option on.


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Anthony PERARD

2011-Jul-18 14:46 UTC

head link

Re: [Xen-devel] Re: [PATCH 3/5] cpu-common: Have a ram_addr_t of uint64 with Xen.

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,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Anthony PERARD

2011-Jul-18 15:29 UTC

head link

Re: [Xen-devel] Re: [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.

On Mon, Jul 18, 2011 at 12:14, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:> On Fri, 15 Jul 2011, Anthony PERARD wrote:
>> On Fri, Jul 15, 2011 at 18:05, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > Shouldn''t we avoid registering any memory for the whole
video ram area?
>> > I mean:
>> >
>> > 0xa0000 - 0x100000
>>
>> No, because SeaBIOS load the Options ROM (VGA Bios, PXE) to the area
>> between 0xc0000 and 0x100000, and this go through QEMU.
>>
>> The area between 0xa0000 and 0xc0000 is registred later by the
>> cirrus_vga bits, as IO.
>
> OK. Can you please expand your comment in the code with the same
> explanation?
Yes, I will do that.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano Stabellini

2011-Jul-18 16:14 UTC

head link

[Xen-devel] Re: [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.

On Fri, 15 Jul 2011, Anthony PERARD wrote:> A Xen guest memory is allocated by libxc. But this memory is not
> allocated continuously, instead, it leaves the VGA IO memory space not
> allocated, same for the MMIO space (at HVM_BELOW_4G_MMIO_START of size
> HVM_BELOW_4G_MMIO_LENGTH).
I realized now that you started using HVM_BELOW_4G_MMIO_START and
HVM_BELOW_4G_MMIO_LENGTH without including xen/hvm/e820.h.
It fails to compile on the latest xen-unstable.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Anthony PERARD

2011-Jul-18 19:42 UTC

head link

Re: [Xen-devel] Re: [PATCH 3/5] cpu-common: Have a ram_addr_t of uint64 with Xen.

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

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

jiageng_yu

2011-Jul-22 07:20 UTC

head link

[Xen-devel] Re: [PATCH 0/5] Enable QEMU to handle more than 2GB with Xen.

Hi Anthony,

   I have questions on CONFIG_XEN_BACKEND in the patches.

   Where to define the CONFIG_XEN_BACKEND option? Due to lacking of
CONFIG_XEN_BACKEND option, the xen_enabled() returns 0 in the phase of
initial qemu machine. How to avoid this problem?

   I am working on qemu-dm-v15 branch, and I wonder if I could apply these
patches without switching branches.

   Thanks!

Jiageng Yu.

--
View this message in context:
http://xen.1045712.n5.nabble.com/PATCH-0-5-Enable-QEMU-to-handle-more-than-2GB-with-Xen-tp4590909p4622050.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Anthony PERARD

2011-Jul-22 11:22 UTC

head link

Re: [Xen-devel] Re: [PATCH 0/5] Enable QEMU to handle more than 2GB with Xen.

On Fri, Jul 22, 2011 at 08:20, jiageng_yu <yujiageng734@gmail.com>
wrote:>   I have questions on CONFIG_XEN_BACKEND in the patches.
>
>   Where to define the CONFIG_XEN_BACKEND option? Due to lacking of
> CONFIG_XEN_BACKEND option, the xen_enabled() returns 0 in the phase of
> initial qemu machine. How to avoid this problem?
>
>   I am working on qemu-dm-v15 branch, and I wonder if I could apply these
> patches without switching branches.
This branch is a little bit old and will never been updated. You can
maybe use this branch:
git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-next
That have recent patches.

Othewise, to apply these patches on your current branch, you can skip
the first patch about xen_enabled as it is just a fix of recent patches,
and try to apply all the other.

You can also replace CONFIG_XEN_BACKEND by CONFIG_XEN on this old
branch.

Regards,


-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Xen devel - Jul 2011 - [PATCH 0/5] Enable QEMU to handle more than 2GB with Xen.

[Xen-devel] [PATCH 0/5] Enable QEMU to handle more than 2GB with Xen.

[Xen-devel] [PATCH 1/5] xen: Fix xen_enabled().

[Xen-devel] [PATCH 2/5] exec.c: Use ram_addr_t in cpu_physical_memory_rw(...).

[Xen-devel] [PATCH 3/5] cpu-common: Have a ram_addr_t of uint64 with Xen.

[Xen-devel] [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.

[Xen-devel] [PATCH 5/5] vl.c: Check the asked ram_size later.

[Xen-devel] Re: [PATCH 2/5] exec.c: Use ram_addr_t in cpu_physical_memory_rw(...).

[Xen-devel] Re: [PATCH 1/5] xen: Fix xen_enabled().

[Xen-devel] Re: [PATCH 5/5] vl.c: Check the asked ram_size later.

[Xen-devel] Re: [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.

[Xen-devel] Re: [PATCH 0/5] Enable QEMU to handle more than 2GB with Xen.

[Xen-devel] Re: [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.

Re: [Xen-devel] Re: [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.

Re: [Xen-devel] Re: [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.

[Xen-devel] Re: [PATCH 3/5] cpu-common: Have a ram_addr_t of uint64 with Xen.

[Xen-devel] Re: [PATCH 0/5] Enable QEMU to handle more than 2GB with Xen.

[Xen-devel] Re: [PATCH 1/5] xen: Fix xen_enabled().

Re: [Xen-devel] Re: [PATCH 3/5] cpu-common: Have a ram_addr_t of uint64 with Xen.

Re: [Xen-devel] Re: [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.

[Xen-devel] Re: [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.

Re: [Xen-devel] Re: [PATCH 3/5] cpu-common: Have a ram_addr_t of uint64 with Xen.

[Xen-devel] Re: [PATCH 0/5] Enable QEMU to handle more than 2GB with Xen.

Re: [Xen-devel] Re: [PATCH 0/5] Enable QEMU to handle more than 2GB with Xen.