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

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

[Anthony PERARD]

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

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

[Anthony PERARD]

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

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

[Anthony PERARD]

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

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

[Anthony PERARD]

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

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

[Paolo Bonzini]

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

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

[Paolo Bonzini]

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

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

[Alexander Graf]

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

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

[Alexander Graf]

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

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

[Anthony PERARD]

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

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

[Anthony PERARD]

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

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

[Paolo Bonzini]

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

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

[Paolo Bonzini]

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

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

[Anthony PERARD]

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

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

[Anthony PERARD]

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

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

[Alexander Graf]

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

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

[Alexander Graf]

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

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

[Anthony PERARD]

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

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

[Anthony PERARD]

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

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

[Anthony PERARD]

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

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

[Anthony PERARD]

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

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

[Anthony PERARD]

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

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

[Anthony PERARD]

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

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

[Paolo Bonzini]

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

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

[Paolo Bonzini]

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

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

[Stefano Stabellini]

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

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

[Stefano Stabellini]

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

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

[Anthony PERARD]

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

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

[Anthony PERARD]

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

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

[Stefano Stabellini]

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?

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

[Stefano Stabellini]

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?

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

[Anthony PERARD]

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

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

[Anthony PERARD]

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

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

[Stefano Stabellini]

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.

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

[Stefano Stabellini]

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.

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

[Anthony PERARD]

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

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

[Anthony PERARD]

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

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

[Paolo Bonzini]

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

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

[Paolo Bonzini]

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

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

[Stefano Stabellini]

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.

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

[Stefano Stabellini]

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.

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

[Alexander Graf]

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

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

[Alexander Graf]

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

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

[jiageng_yu]

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.

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

[Anthony PERARD]

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