[Qemu-devel] [PATCH 0/6] Xen patch queue 2011-07-20

[Qemu-devel] [PATCH 0/6] Xen patch queue 2011-07-20

[Alexander Graf]

Hi Anthony,

This is my current patch queue for Xen stuff that fixes even more regressions
introduced by recent Xen patches. I hope this time we're regression-free.

Please pull.

Alex

The following changes since commit 03ff09580ef6cbc4a893b6e3e6bbff33180ec70a:
  Anthony Liguori (1):
        Merge remote-tracking branch 'agraf/xen-next' into staging

are available in the git repository at:

  git://repo.or.cz/qemu/agraf.git xen-next

Alexander Graf (3):
  xen: add mapcache stubs
  xen: remove CONFIG_XEN_MAPCACHE
  xen: make xen_enabled even more clever

Anthony PERARD (3):
  xen: introduce xen_change_state_handler
  xen: Fix xen_enabled().
  exec.c: Use ram_addr_t in cpu_physical_memory_rw(...).

 configure  |    8 +++++---
 exec.c     |    4 ++--
 hw/xen.h   |    2 +-
 xen-all.c  |   25 ++++++++++++++++++-------
 xen-stub.c |   26 ++++++++++++++++++++++++++
 5 files changed, 52 insertions(+), 13 deletions(-)

[Qemu-devel] [PATCH 1/6] xen: introduce xen_change_state_handler

[Alexander Graf]

From: Anthony PERARD <anthony.perard@citrix.com>

Remove the call to xenstore_record_dm_state from xen_main_loop_prepare
that is HVM specific.
Add a new vm_change_state_handler shared between xen_pv and xen_hvm
machines to record the VM state to xenstore.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 xen-all.c |   25 ++++++++++++++++++-------
 1 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 8105c83..5fa92ae 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -797,12 +797,17 @@ void xenstore_store_pv_console_info(int i, CharDriverState *chr)
     }
 }
 
-static void xenstore_record_dm_state(XenIOState *s, const char *state)
+static void xenstore_record_dm_state(struct xs_handle *xs, const char *state)
 {
     char path[50];
 
+    if (xs == NULL) {
+        fprintf(stderr, "xenstore connection not initialized\n");
+        exit(1);
+    }
+
     snprintf(path, sizeof (path), "/local/domain/0/device-model/%u/state", xen_domid);
-    if (!xs_write(s->xenstore, XBT_NULL, path, state, strlen(state))) {
+    if (!xs_write(xs, XBT_NULL, path, state, strlen(state))) {
         fprintf(stderr, "error recording dm state\n");
         exit(1);
     }
@@ -823,15 +828,20 @@ static void xen_main_loop_prepare(XenIOState *state)
     if (evtchn_fd != -1) {
         qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, state);
     }
-
-    /* record state running */
-    xenstore_record_dm_state(state, "running");
 }
 
 
 /* Initialise Xen */
 
-static void xen_vm_change_state_handler(void *opaque, int running, int reason)
+static void xen_change_state_handler(void *opaque, int running, int reason)
+{
+    if (running) {
+        /* record state running */
+        xenstore_record_dm_state(xenstore, "running");
+    }
+}
+
+static void xen_hvm_change_state_handler(void *opaque, int running, int reason)
 {
     XenIOState *state = opaque;
     if (running) {
@@ -854,6 +864,7 @@ int xen_init(void)
         xen_be_printf(NULL, 0, "can't open xen interface\n");
         return -1;
     }
+    qemu_add_vm_change_state_handler(xen_change_state_handler, NULL);
 
     return 0;
 }
@@ -915,7 +926,7 @@ int xen_hvm_init(void)
     xen_map_cache_init();
     xen_ram_init(ram_size);
 
-    qemu_add_vm_change_state_handler(xen_vm_change_state_handler, state);
+    qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
 
     state->client = xen_cpu_phys_memory_client;
     QLIST_INIT(&state->physmap);
-- 
1.6.0.2

[Qemu-devel] [PATCH 2/6] xen: add mapcache stubs

[Alexander Graf]

During the transition to get rid of CONFIG_XEN_MAPCACHE we lost the mapcache
stubs along the way. Nobody realized it because the commands were guarded by
if (xen_enabled()) clauses that made gcc optimize out the respective calls.

This patch adds the stubs again - this time in the generic xen-stubs.c

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 xen-stub.c |   26 ++++++++++++++++++++++++++
 1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/xen-stub.c b/xen-stub.c
index efe2ab5..76d80e9 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -8,6 +8,7 @@
 
 #include "qemu-common.h"
 #include "hw/xen.h"
+#include "xen-mapcache.h"
 
 void xenstore_store_pv_console_info(int i, CharDriverState *chr)
 {
@@ -43,3 +44,28 @@ int xen_init(void)
 {
     return -ENOSYS;
 }
+
+/******* mapcache stubs *******/
+
+void xen_map_cache_init(void)
+{
+}
+
+uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
+                       uint8_t lock)
+{
+    return qemu_get_ram_ptr(phys_addr);
+}
+
+ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
+{
+    return -1;
+}
+
+void xen_invalidate_map_cache(void)
+{
+}
+
+void xen_invalidate_map_cache_entry(uint8_t *buffer)
+{
+}
-- 
1.6.0.2

[Qemu-devel] [PATCH 3/6] xen: Fix xen_enabled().

[Alexander Graf]

From: Anthony PERARD <anthony.perard@citrix.com>

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

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 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;
-- 
1.6.0.2

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

[Alexander Graf]

From: Anthony PERARD <anthony.perard@citrix.com>

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>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 exec.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/exec.c b/exec.c
index 8277900..8ef290e 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);
-- 
1.6.0.2

[Qemu-devel] [PATCH 5/6] xen: remove CONFIG_XEN_MAPCACHE

[Alexander Graf]

We were still exporting CONFIG_XEN_MAPCACHE, even though it's completely
unused by now. Remove it.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 configure |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index e57efb1..f537130 100755
--- a/configure
+++ b/configure
@@ -3235,9 +3235,6 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
-      if test "$cpu" = "i386" -o "$cpu" = "x86_64"; then
-          echo "CONFIG_XEN_MAPCACHE=y" >> $config_target_mak
-      fi
     fi
 esac
 case "$target_arch2" in
-- 
1.6.0.2

[Qemu-devel] [PATCH 6/6] xen: make xen_enabled even more clever

[Alexander Graf]

When using xen_enabled() we're currently only checking if xen is enabled
at all during the build. But what if you want to build multiple targets
out of which only one can potentially run xen code?

That means that for generic code we'll still have to fall back to the
variable and potentially slow the code down, but it's not as important as
that is mostly xen device emulation which is not touched for non-xen targets.

The target specific code however can with this patch see that it's unable to
ever execute xen code. We can thus always return 0 on xen_enabled(), giving
gcc enough hints to evict the mapcache code from the target memory management
code.

Signed-off-by: Alexander Graf <agraf@suse.de>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
---
 configure |    5 +++++
 hw/xen.h  |    2 +-
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/configure b/configure
index f537130..f79b23b 100755
--- a/configure
+++ b/configure
@@ -3235,7 +3235,12 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+    else
+      echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
+    ;;
+  *)
+    echo "CONFIG_NO_XEN=y" >> $config_target_mak
 esac
 case "$target_arch2" in
   i386|x86_64|ppcemb|ppc|ppc64|s390x)
diff --git a/hw/xen.h b/hw/xen.h
index 43b95d6..2162111 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_BACKEND
+#if defined(CONFIG_XEN_BACKEND) && !defined(CONFIG_NO_XEN)
     return xen_allowed;
 #else
     return 0;
-- 
1.6.0.2

Re: [Qemu-devel] [PATCH 0/6] Xen patch queue 2011-07-20

[Alexander Graf]

On 19.07.2011, at 04:53, Alexander Graf wrote:

> Hi Anthony,
> 
> This is my current patch queue for Xen stuff that fixes even more regressions
> introduced by recent Xen patches. I hope this time we're regression-free.

Again, this is obviously a [PULL] mail :). I really need to improve on checking that part of the subject line.

> 
> Please pull.
> 
> Alex
> 
> The following changes since commit 03ff09580ef6cbc4a893b6e3e6bbff33180ec70a:
>  Anthony Liguori (1):
>        Merge remote-tracking branch 'agraf/xen-next' into staging
> 
> are available in the git repository at:
> 
>  git://repo.or.cz/qemu/agraf.git xen-next
> 
> Alexander Graf (3):
>  xen: add mapcache stubs
>  xen: remove CONFIG_XEN_MAPCACHE
>  xen: make xen_enabled even more clever
> 
> Anthony PERARD (3):
>  xen: introduce xen_change_state_handler
>  xen: Fix xen_enabled().
>  exec.c: Use ram_addr_t in cpu_physical_memory_rw(...).
> 
> configure  |    8 +++++---
> exec.c     |    4 ++--
> hw/xen.h   |    2 +-
> xen-all.c  |   25 ++++++++++++++++++-------
> xen-stub.c |   26 ++++++++++++++++++++++++++
> 5 files changed, 52 insertions(+), 13 deletions(-)
> 
> 

Re: [Qemu-devel] [PATCH 2/6] xen: add mapcache stubs

[Avi Kivity]

On 07/19/2011 05:53 AM, Alexander Graf wrote:
> During the transition to get rid of CONFIG_XEN_MAPCACHE we lost the mapcache
> stubs along the way. Nobody realized it because the commands were guarded by
> if (xen_enabled()) clauses that made gcc optimize out the respective calls.
>

Except those building with --enable-debug.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH 2/6] xen: add mapcache stubs

[Alexander Graf]

On 20.07.2011, at 17:12, Avi Kivity wrote:

> On 07/19/2011 05:53 AM, Alexander Graf wrote:
>> During the transition to get rid of CONFIG_XEN_MAPCACHE we lost the mapcache
>> stubs along the way. Nobody realized it because the commands were guarded by
>> if (xen_enabled()) clauses that made gcc optimize out the respective calls.
>> 
> 
> Except those building with --enable-debug.

Ah, that's how you caught it. I was wondering already :). Right, --enable-debug also catches it.


Alex

Re: [Qemu-devel] [PATCH 2/6] xen: add mapcache stubs

[Stefan Weil]

Am 19.07.2011 04:53, schrieb Alexander Graf:
> During the transition to get rid of CONFIG_XEN_MAPCACHE we lost the 
> mapcache
> stubs along the way. Nobody realized it because the commands were 
> guarded by
> if (xen_enabled()) clauses that made gcc optimize out the respective 
> calls.
>
> This patch adds the stubs again - this time in the generic xen-stubs.c
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
> xen-stub.c | 26 ++++++++++++++++++++++++++
> 1 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/xen-stub.c b/xen-stub.c
> index efe2ab5..76d80e9 100644
> --- a/xen-stub.c
> +++ b/xen-stub.c
> @@ -8,6 +8,7 @@
>
> #include "qemu-common.h"
> #include "hw/xen.h"
> +#include "xen-mapcache.h"
>
> void xenstore_store_pv_console_info(int i, CharDriverState *chr)
> {
> @@ -43,3 +44,28 @@ int xen_init(void)
> {
> return -ENOSYS;
> }
> +
> +/******* mapcache stubs *******/
> +
> +void xen_map_cache_init(void)
> +{
> +}
> +
> +uint8_t *xen_map_cache(target_phys_addr_t phys_addr, 
> target_phys_addr_t size,
> + uint8_t lock)
> +{
> + return qemu_get_ram_ptr(phys_addr);
> +}
> +
> +ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
> +{
> + return -1;
> +}
> +
> +void xen_invalidate_map_cache(void)
> +{
> +}
> +
> +void xen_invalidate_map_cache_entry(uint8_t *buffer)
> +{
> +}

The patch fixes a build problem, and the sooner we fix it,
the better it is.

Do we really need a return value other than NULL in xen_map_cache()?
Do we need the stubs for xen_map_cache_init() and 
xen_invalidate_map_cache()?
As discussed in another thread, static inline stub function might be better.

Regards,
Stefan W.

Re: [Qemu-devel] [PATCH 2/6] xen: add mapcache stubs

[Alexander Graf]

On 20.07.2011, at 18:41, Stefan Weil wrote:

> Am 19.07.2011 04:53, schrieb Alexander Graf:
>> During the transition to get rid of CONFIG_XEN_MAPCACHE we lost the mapcache
>> stubs along the way. Nobody realized it because the commands were guarded by
>> if (xen_enabled()) clauses that made gcc optimize out the respective calls.
>> 
>> This patch adds the stubs again - this time in the generic xen-stubs.c
>> 
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>> xen-stub.c | 26 ++++++++++++++++++++++++++
>> 1 files changed, 26 insertions(+), 0 deletions(-)
>> 
>> diff --git a/xen-stub.c b/xen-stub.c
>> index efe2ab5..76d80e9 100644
>> --- a/xen-stub.c
>> +++ b/xen-stub.c
>> @@ -8,6 +8,7 @@
>> 
>> #include "qemu-common.h"
>> #include "hw/xen.h"
>> +#include "xen-mapcache.h"
>> 
>> void xenstore_store_pv_console_info(int i, CharDriverState *chr)
>> {
>> @@ -43,3 +44,28 @@ int xen_init(void)
>> {
>> return -ENOSYS;
>> }
>> +
>> +/******* mapcache stubs *******/
>> +
>> +void xen_map_cache_init(void)
>> +{
>> +}
>> +
>> +uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
>> + uint8_t lock)
>> +{
>> + return qemu_get_ram_ptr(phys_addr);
>> +}
>> +
>> +ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
>> +{
>> + return -1;
>> +}
>> +
>> +void xen_invalidate_map_cache(void)
>> +{
>> +}
>> +
>> +void xen_invalidate_map_cache_entry(uint8_t *buffer)
>> +{
>> +}
> 
> The patch fixes a build problem, and the sooner we fix it,
> the better it is.
> 
> Do we really need a return value other than NULL in xen_map_cache()?
> Do we need the stubs for xen_map_cache_init() and xen_invalidate_map_cache()?
> As discussed in another thread, static inline stub function might be better.

I'm fairly sure we don't, but I merely shoved everything that was in xen-mapcache-stubs.c into xen-stubs.c. We can concentrate on optimizing this out again when the build works. If we really care about it.


Alex