Skip to contentSkip to conversation

Xen cleanups

PATCH Superseded Jan Kiszka 5 participants 24 messages Jun 21, 2011 Kbuild

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Jan Kiszka

author
#0 lore raw

cover Xen cleanups

I came across some Xen oddities I couldn't help to clean up. These patches
- simplify the build
- remove a win32 breakage from xen-mapcache.h
- move the map cache functions out of the generic name space

Jan Kiszka (4):
xen: Clean up build system
xen: Uninline xen_unmap_block
xen: Clean up map cache API naming
xen: Fold CONFIG_XEN_MAPCACHE into CONFIG_XEN

 Makefile.objs       |    4 +-
 Makefile.target     |   14 +-----------
 configure           |    5 +---
 exec.c              |   25 ++++++++++++-----------
 hw/xen.h            |    9 --------
 trace-events        |    6 ++--
 xen-all.c           |    4 +-
 xen-mapcache-stub.c |   44 -------------------------------------------
 xen-mapcache.c      |   52 ++++++++++++++++++++++++++++++++------------------
 xen-mapcache.h      |   30 +++++++---------------------
 xen-stub.c          |   29 ++++++++++++++++++++++++++++
 11 files changed, 93 insertions(+), 129 deletions(-)
 delete mode 100644 xen-mapcache-stub.c
author
#1 lore raw

PATCH 1/4 xen: Clean up build system

From: Jan Kiszka <[email protected]>

Introduce CONFIG_XEN_BACKEND so that this new config solely controls the target-independent backend build and CONFIG_XEN can focus on per-target building.

---
 Makefile.objs   |    4 ++--
 Makefile.target |   13 +++----------
 configure       |    2 +-
 3 files changed, 6 insertions(+), 13 deletions(-)
Makefile.objs +2 -2
index cea15e4..1635df6 100644
@@ -155,8 +155,8 @@ slirp-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o
 common-obj-$(CONFIG_SLIRP) += $(addprefix slirp/, $(slirp-obj-y))
 
 # xen backend driver support
-common-obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o
-common-obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o
+common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
+common-obj-$(CONFIG_XEN_BACKEND) += xen_console.o xenfb.o xen_disk.o xen_nic.o
 
 ######################################################################
 # libuser
Makefile.target +3 -10
index b1a0f6d..f325554 100644
@@ -3,6 +3,8 @@
 GENERATED_HEADERS = config-target.h
 CONFIG_NO_PCI = $(if $(subst n,,$(CONFIG_PCI)),n,y)
 CONFIG_NO_KVM = $(if $(subst n,,$(CONFIG_KVM)),n,y)
+CONFIG_NO_XEN = $(if $(subst n,,$(CONFIG_XEN)),n,y)
+CONFIG_NO_XEN_MAPCACHE = $(if $(subst n,,$(CONFIG_XEN_MAPCACHE)),n,y)
 
 include ../config-host.mak
 include config-devices.mak
@@ -203,17 +205,8 @@ QEMU_CFLAGS += $(VNC_SASL_CFLAGS)
 QEMU_CFLAGS += $(VNC_JPEG_CFLAGS)
 QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
 
-# xen backend driver support
-obj-i386-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o
-
-ifeq ($(TARGET_BASE_ARCH), i386)
-  CONFIG_NO_XEN = $(if $(subst n,,$(CONFIG_XEN)),n,y)
-else
-  CONFIG_NO_XEN = y
-endif
 # xen support
-CONFIG_NO_XEN_MAPCACHE = $(if $(subst n,,$(CONFIG_XEN_MAPCACHE)),n,y)
-obj-i386-$(CONFIG_XEN) += xen-all.o
+obj-$(CONFIG_XEN) += xen-all.o xen_machine_pv.o xen_domainbuild.o
 obj-$(CONFIG_NO_XEN) += xen-stub.o
 obj-i386-$(CONFIG_XEN_MAPCACHE) += xen-mapcache.o
 obj-$(CONFIG_NO_XEN_MAPCACHE) += xen-mapcache-stub.o
configure +1 -1
index 44c092a..7991489 100755
@@ -2944,7 +2944,7 @@ if test "$bluez" = "yes" ; then
   echo "BLUEZ_CFLAGS=$bluez_cflags" >> $config_host_mak
 fi
 if test "$xen" = "yes" ; then
-  echo "CONFIG_XEN=y" >> $config_host_mak
+  echo "CONFIG_XEN_BACKEND=y" >> $config_host_mak
   echo "CONFIG_XEN_CTRL_INTERFACE_VERSION=$xen_ctrl_version" >> $config_host_mak
 fi
 if test "$io_thread" = "yes" ; then
Signature · 1 line
1.7.1
#2 lore raw

Re: [Qemu-devel] [PATCH 1/4] xen: Clean up build system

Quoted 5 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

Introduce CONFIG_XEN_BACKEND so that this new config solely controls the target-independent backend build and CONFIG_XEN can focus on per-target building.

What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.

Alex

author
#3 lore raw

Re: [Qemu-devel] [PATCH 1/4] xen: Clean up build system

Quoted 10 lines · Alexander Graf
Quoted 5 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

Introduce CONFIG_XEN_BACKEND so that this new config solely controls the target-independent backend build and CONFIG_XEN can focus on per-target building.

What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.

I doubt that as well. But keeping the backend centrals prevent building them twice (for i386 and x86_64).

Jan

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#4 lore raw

Re: [Qemu-devel] [PATCH 1/4] xen: Clean up build system

Quoted 6 lines · Jan Kiszka
Quoted 5 lines · Alexander Graf
Quoted 2 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

Introduce CONFIG_XEN_BACKEND so that this new config solely controls the target-independent backend build and CONFIG_XEN can focus on per-target building.

What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.

I doubt that as well. But keeping the backend centrals prevent building them twice (for i386 and x86_64).

How can we not build them twice without risking that target_ulong breaks somewhere along the way?

Alex

author
#5 lore raw

Re: [Qemu-devel] [PATCH 1/4] xen: Clean up build system

Quoted 13 lines · Alexander Graf
Quoted 10 lines · Jan Kiszka
Quoted 9 lines · Alexander Graf
Quoted 5 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

Introduce CONFIG_XEN_BACKEND so that this new config solely controls the target-independent backend build and CONFIG_XEN can focus on per-target building.

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.

I doubt that as well. But keeping the backend centrals prevent building them twice (for i386 and x86_64).

How can we not build them twice without risking that target_ulong breaks somewhere along the way?

Because the backends don't depend on that. And we already build them only once, your your logs. :)

Jan

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#6 lore raw

Re: [Qemu-devel] [PATCH 1/4] xen: Clean up build system

Quoted 16 lines · Jan Kiszka
Quoted 15 lines · Alexander Graf
Quoted 12 lines · Jan Kiszka
Quoted 10 lines · Alexander Graf
Quoted 5 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

Introduce CONFIG_XEN_BACKEND so that this new config solely controls the target-independent backend build and CONFIG_XEN can focus on per-target building.

What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

I doubt that as well. But keeping the backend centrals prevent building them twice (for i386 and x86_64).

How can we not build them twice without risking that target_ulong breaks somewhere along the way?

Because the backends don't depend on that. And we already build them only once, your your logs. :)

So what does the patch change then if it's already only built once?

Alex

author
#7 lore raw

Re: [Qemu-devel] [PATCH 1/4] xen: Clean up build system

Quoted 22 lines · Alexander Graf
Quoted 19 lines · Jan Kiszka
Quoted 18 lines · Alexander Graf
Quoted 14 lines · Jan Kiszka
Quoted 10 lines · Alexander Graf
Quoted 5 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

Introduce CONFIG_XEN_BACKEND so that this new config solely controls the target-independent backend build and CONFIG_XEN can focus on per-target building.

What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.

I doubt that as well. But keeping the backend centrals prevent building them twice (for i386 and x86_64).

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

How can we not build them twice without risking that target_ulong breaks somewhere along the way?

Because the backends don't depend on that. And we already build them only once, your your logs. :)

So what does the patch change then if it's already only built once?

It allows to clean up Makefile.target like I did as CONFIG_XEN is no longer defined for all targets but only for those that actually support Xen.

Jan

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#8 lore raw

Re: [Qemu-devel] [PATCH 1/4] xen: Clean up build system

Quoted 25 lines · Jan Kiszka
Quoted 24 lines · Alexander Graf
Quoted 21 lines · Jan Kiszka
Quoted 19 lines · Alexander Graf
Quoted 6 lines · Jan Kiszka
Quoted 5 lines · Alexander Graf
Quoted 2 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

Introduce CONFIG_XEN_BACKEND so that this new config solely controls the target-independent backend build and CONFIG_XEN can focus on per-target building.

What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.

I doubt that as well. But keeping the backend centrals prevent building them twice (for i386 and x86_64).

How can we not build them twice without risking that target_ulong breaks somewhere along the way?

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

Because the backends don't depend on that. And we already build them only once, your your logs. :)

So what does the patch change then if it's already only built once?

It allows to clean up Makefile.target like I did as CONFIG_XEN is no longer defined for all targets but only for those that actually support Xen.

Seems to make sense. Let's hope it doesn't break anything :)

Alex

#9 lore raw

[Qemu-devel] [Xen-devel] Re: [PATCH 1/4] xen: Clean up build system

In reply to Alexander Graf

Alexander Graf writes ("[Xen-devel] Re: [PATCH 1/4] xen: Clean up build system"):

Quoted 10 lines · Jan Kiszka
Quoted 5 lines

From: Jan Kiszka <[email protected]>

Introduce CONFIG_XEN_BACKEND so that this new config solely controls the target-independent backend build and CONFIG_XEN can focus on per-target building.

What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.

In the past Xen has supported ppc too and there is a half-congealed arm port. It's not a good assumption that Xen is x86-specific.

Ian.

#10 lore raw

Re: [Qemu-devel] [Xen-devel] Re: [PATCH 1/4] xen: Clean up build system

Quoted 8 lines · Ian Jackson

Alexander Graf writes ("[Xen-devel] Re: [PATCH 1/4] xen: Clean up build system"):

Quoted 7 lines · Jan Kiszka
Quoted 5 lines

From: Jan Kiszka <[email protected]>

Introduce CONFIG_XEN_BACKEND so that this new config solely controls the target-independent backend build and CONFIG_XEN can focus on per-target building.

Quoted 6 lines
Quoted 3 lines

What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.

In the past Xen has supported ppc too and there is a half-congealed arm port. It's not a good assumption that Xen is x86-specific.

We aren't setting x86 dependency into stone here, we are just trying to keep support for what is there today clean and simple. The build system can become more advanced again once there is support for modern ARM or PowerPC. But until other Xen archs materialize into a usable form, it's futile to design for their past or possible future requirements. KVM is also no longer considering IA64 when cleaning up.

Jan

Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
#11 lore raw

Re: [Qemu-devel] [Xen-devel] Re: [PATCH 1/4] xen: Clean up build system

In reply to Ian Jackson
Quoted 8 lines · Ian Jackson

Alexander Graf writes ("[Xen-devel] Re: [PATCH 1/4] xen: Clean up build system"):

Quoted 7 lines · Jan Kiszka
Quoted 5 lines

From: Jan Kiszka <[email protected]>

Introduce CONFIG_XEN_BACKEND so that this new config solely controls the target-independent backend build and CONFIG_XEN can focus on per-target building.

Quoted 6 lines
Quoted 3 lines

What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.

In the past Xen has supported ppc too and there is a half-congealed arm port. It's not a good assumption that Xen is x86-specific.

Well, is there a realistic chance that we'll ever get non-x86 Xen code into upstream Qemu? I don't know how well the arm port's been doing, but the PPC one is long dead and was always just a toy. I'm fairly sure nobody really cares about the IA64 port either these days.

Alex

#12 lore raw

Re: [Qemu-devel] [Xen-devel] Re: [PATCH 1/4] xen: Clean up build system

Quoted 10 lines · Alexander Graf
Quoted 8 lines · Ian Jackson

Alexander Graf writes ("[Xen-devel] Re: [PATCH 1/4] xen: Clean up build system"):

Quoted 7 lines · Jan Kiszka
Quoted 5 lines

From: Jan Kiszka <[email protected]>

Introduce CONFIG_XEN_BACKEND so that this new config solely controls the target-independent backend build and CONFIG_XEN can focus on per-target building.

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines

What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.

In the past Xen has supported ppc too and there is a half-congealed arm port. It's not a good assumption that Xen is x86-specific.

Well, is there a realistic chance that we'll ever get non-x86 Xen code into upstream Qemu? I don't know how well the arm port's been doing, but the PPC one is long dead and was always just a toy. I'm fairly sure nobody really cares about the IA64 port either these days.

There is a realistic chance we'll get ARM Xen code into upstream Qemu. That said, I don't think this patch would prevent it from happening. Also I tested it and it works OK, so it is fine by me.

author
#13 lore raw

PATCH 2/4 xen: Uninline xen_unmap_block

In reply to Jan Kiszka

From: Jan Kiszka <[email protected]>

No reason to inline this helper. Also, cleaning up the header unbreaks non-UNIX building where sys/mman.h is not available.

---
 exec.c              |    1 +
 xen-mapcache-stub.c |    4 ++++
 xen-mapcache.c      |    9 +++++++++
 xen-mapcache.h      |   14 +-------------
 4 files changed, 15 insertions(+), 13 deletions(-)
exec.c +1 -0
index 09928a3..41ba883 100644
@@ -34,6 +34,7 @@
 #include "kvm.h"
 #include "hw/xen.h"
 #include "qemu-timer.h"
+#include "trace.h"
 #if defined(CONFIG_USER_ONLY)
 #include <qemu.h>
 #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
xen-mapcache-stub.c +4 -0
index 7c14b3d..dfecbdd 100644
@@ -42,3 +42,7 @@ uint8_t *xen_map_block(target_phys_addr_t phys_addr, target_phys_addr_t size)
 {
     return NULL;
 }
+
+void xen_unmap_block(void *addr, ram_addr_t size)
+{
+}
xen-mapcache.c +9 -0
index 349cc62..4c663e6 100644
@@ -373,3 +373,12 @@ uint8_t *xen_map_block(target_phys_addr_t phys_addr, target_phys_addr_t size)
 
     return vaddr_base;
 }
+
+void xen_unmap_block(void *addr, ram_addr_t size)
+{
+    trace_xen_unmap_block(addr, size);
+
+    if (munmap(addr, size) != 0) {
+        hw_error("xen_unmap_block: %s", strerror(errno));
+    }
+}
xen-mapcache.h +1 -13
index 339444c..f7b4c04 100644
@@ -9,9 +9,6 @@
 #ifndef XEN_MAPCACHE_H
 #define XEN_MAPCACHE_H
 
-#include <sys/mman.h>
-#include "trace.h"
-
 void     qemu_map_cache_init(void);
 uint8_t  *qemu_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size, uint8_t lock);
 void     qemu_map_cache_unlock(void *phys_addr);
@@ -20,16 +17,7 @@ void     qemu_invalidate_entry(uint8_t *buffer);
 void     qemu_invalidate_map_cache(void);
 
 uint8_t *xen_map_block(target_phys_addr_t phys_addr, target_phys_addr_t size);
-
-static inline void xen_unmap_block(void *addr, ram_addr_t size)
-{
-    trace_xen_unmap_block(addr, size);
-
-    if (munmap(addr, size) != 0) {
-        hw_error("xen_unmap_block: %s", strerror(errno));
-    }
-}
-
+void xen_unmap_block(void *addr, ram_addr_t size);
 
 #define mapcache_lock()   ((void)0)
 #define mapcache_unlock() ((void)0)
Signature · 1 line
1.7.1
#14 lore raw

Re: [Qemu-devel] [PATCH 2/4] xen: Uninline xen_unmap_block

Quoted 4 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

No reason to inline this helper. Also, cleaning up the header unbreaks non-UNIX building where sys/mman.h is not available.

Looks good to me. Stefano, please ack.

Alex

#15 lore raw

Re: [Qemu-devel] [PATCH 2/4] xen: Uninline xen_unmap_block

Quoted 8 lines · Alexander Graf
Quoted 4 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

No reason to inline this helper. Also, cleaning up the header unbreaks non-UNIX building where sys/mman.h is not available.

Looks good to me. Stefano, please ack.

author
#16 lore raw

PATCH 3/4 xen: Clean up map cache API naming

In reply to Jan Kiszka

From: Jan Kiszka <[email protected]>

The map cache is a Xen thing, so its API should make this clear.

---
 exec.c              |   10 +++++-----
 trace-events        |    6 +++---
 xen-all.c           |    4 ++--
 xen-mapcache-stub.c |   13 +++++++------
 xen-mapcache.c      |   43 ++++++++++++++++++++++++-------------------
 xen-mapcache.h      |   16 +++++++---------
 6 files changed, 48 insertions(+), 44 deletions(-)
exec.c +5 -5
index 41ba883..91751c5 100644
@@ -2990,7 +2990,7 @@ void qemu_ram_free(ram_addr_t addr)
                 munmap(block->host, block->length);
 #else
                 if (xen_mapcache_enabled()) {
-                    qemu_invalidate_entry(block->host);
+                    xen_invalidate_map_cache_entry(block->host);
                 } else {
                     qemu_vfree(block->host);
                 }
@@ -3087,7 +3087,7 @@ void *qemu_get_ram_ptr(ram_addr_t addr)
                  * because we don't want to map the entire memory in QEMU.
                  */
                 if (block->offset == 0) {
-                    return qemu_map_cache(addr, 0, 1);
+                    return xen_map_cache(addr, 0, 1);
                 } else if (block->host == NULL) {
                     block->host = xen_map_block(block->offset, block->length);
                 }
@@ -3116,7 +3116,7 @@ void *qemu_safe_ram_ptr(ram_addr_t addr)
                  * because we don't want to map the entire memory in QEMU.
                  */
                 if (block->offset == 0) {
-                    return qemu_map_cache(addr, 0, 1);
+                    return xen_map_cache(addr, 0, 1);
                 } else if (block->host == NULL) {
                     block->host = xen_map_block(block->offset, block->length);
                 }
@@ -3147,7 +3147,7 @@ void qemu_put_ram_ptr(void *addr)
             xen_unmap_block(block->host, block->length);
             block->host = NULL;
         } else {
-            qemu_map_cache_unlock(addr);
+            xen_map_cache_unlock(addr);
         }
     }
 }
@@ -3169,7 +3169,7 @@ int qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr)
     }
 
     if (xen_mapcache_enabled()) {
-        *ram_addr = qemu_ram_addr_from_mapcache(ptr);
+        *ram_addr = xen_ram_addr_from_mapcache(ptr);
         return 0;
     }
 
trace-events +3 -3
index f1230f1..a2839dd 100644
@@ -398,9 +398,9 @@ disable milkymist_vgafb_memory_write(uint32_t addr, uint32_t value) "addr %08x v
 disable xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested: %#lx, size %#lx"
 
 # xen-mapcache.c
-disable qemu_map_cache(uint64_t phys_addr) "want %#"PRIx64""
-disable qemu_remap_bucket(uint64_t index) "index %#"PRIx64""
-disable qemu_map_cache_return(void* ptr) "%p"
+disable xen_map_cache(uint64_t phys_addr) "want %#"PRIx64""
+disable xen_remap_bucket(uint64_t index) "index %#"PRIx64""
+disable xen_map_cache_return(void* ptr) "%p"
 disable xen_map_block(uint64_t phys_addr, uint64_t size) "%#"PRIx64", size %#"PRIx64""
 disable xen_unmap_block(void* addr, unsigned long size) "%p, size %#lx"
 
xen-all.c +2 -2
index 0eac202..7346751 100644
@@ -368,7 +368,7 @@ static void handle_ioreq(ioreq_t *req)
         case IOREQ_TYPE_TIMEOFFSET:
             break;
         case IOREQ_TYPE_INVALIDATE:
-            qemu_invalidate_map_cache();
+            xen_invalidate_map_cache();
             break;
         default:
             hw_error("Invalid ioreq type 0x%x\n", req->type);
@@ -576,7 +576,7 @@ int xen_hvm_init(void)
     }
 
     /* Init RAM management */
-    qemu_map_cache_init();
+    xen_map_cache_init();
     xen_ram_init(ram_size);
 
     qemu_add_vm_change_state_handler(xen_vm_change_state_handler, state);
xen-mapcache-stub.c +7 -6
index dfecbdd..6ee0dc8 100644
@@ -13,29 +13,30 @@
 #include "cpu-common.h"
 #include "xen-mapcache.h"
 
-void qemu_map_cache_init(void)
+void xen_map_cache_init(void)
 {
 }
 
-uint8_t *qemu_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size, uint8_t lock)
+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);
 }
 
-void qemu_map_cache_unlock(void *buffer)
+void xen_map_cache_unlock(void *buffer)
 {
 }
 
-ram_addr_t qemu_ram_addr_from_mapcache(void *ptr)
+ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
 {
     return -1;
 }
 
-void qemu_invalidate_map_cache(void)
+void xen_invalidate_map_cache(void)
 {
 }
 
-void qemu_invalidate_entry(uint8_t *buffer)
+void xen_invalidate_map_cache_entry(uint8_t *buffer)
 {
 }
 uint8_t *xen_map_block(target_phys_addr_t phys_addr, target_phys_addr_t size)
xen-mapcache.c +24 -19

136 lines not on this page · raw message

xen-mapcache.h +7 -9
index f7b4c04..b46c971 100644
@@ -9,17 +9,15 @@
 #ifndef XEN_MAPCACHE_H
 #define XEN_MAPCACHE_H
 
-void     qemu_map_cache_init(void);
-uint8_t  *qemu_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size, uint8_t lock);
-void     qemu_map_cache_unlock(void *phys_addr);
-ram_addr_t qemu_ram_addr_from_mapcache(void *ptr);
-void     qemu_invalidate_entry(uint8_t *buffer);
-void     qemu_invalidate_map_cache(void);
+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);
+void xen_map_cache_unlock(void *phys_addr);
+ram_addr_t xen_ram_addr_from_mapcache(void *ptr);
+void xen_invalidate_map_cache_entry(uint8_t *buffer);
+void xen_invalidate_map_cache(void);
 
 uint8_t *xen_map_block(target_phys_addr_t phys_addr, target_phys_addr_t size);
 void xen_unmap_block(void *addr, ram_addr_t size);
 
-#define mapcache_lock()   ((void)0)
-#define mapcache_unlock() ((void)0)
-
 #endif /* !XEN_MAPCACHE_H */
Signature · 1 line
1.7.1
#17 lore raw

Re: [Qemu-devel] [PATCH 3/4] xen: Clean up map cache API naming

Quoted 3 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

The map cache is a Xen thing, so its API should make this clear.

Also looks good. Stefano, please ack.

Alex

author
#19 lore raw

PATCH 4/4 xen: Fold CONFIG_XEN_MAPCACHE into CONFIG_XEN

In reply to Jan Kiszka

From: Jan Kiszka <[email protected]>

Xen won't be enabled if there is no backend support available for the host. And that also means the map cache will work. So drop the separate config switch and move the required stubs over to xen-stub.c.

---
 Makefile.target     |    5 +----
 configure           |    3 ---
 exec.c              |   14 +++++++-------
 hw/xen.h            |    9 ---------
 xen-mapcache-stub.c |   49 -------------------------------------------------
 xen-stub.c          |   29 +++++++++++++++++++++++++++++
 6 files changed, 37 insertions(+), 72 deletions(-)
 delete mode 100644 xen-mapcache-stub.c
Makefile.target +1 -4
index f325554..2507466 100644
@@ -4,7 +4,6 @@ GENERATED_HEADERS = config-target.h
 CONFIG_NO_PCI = $(if $(subst n,,$(CONFIG_PCI)),n,y)
 CONFIG_NO_KVM = $(if $(subst n,,$(CONFIG_KVM)),n,y)
 CONFIG_NO_XEN = $(if $(subst n,,$(CONFIG_XEN)),n,y)
-CONFIG_NO_XEN_MAPCACHE = $(if $(subst n,,$(CONFIG_XEN_MAPCACHE)),n,y)
 
 include ../config-host.mak
 include config-devices.mak
@@ -206,10 +205,8 @@ QEMU_CFLAGS += $(VNC_JPEG_CFLAGS)
 QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
 
 # xen support
-obj-$(CONFIG_XEN) += xen-all.o xen_machine_pv.o xen_domainbuild.o
+obj-$(CONFIG_XEN) += xen-all.o xen_machine_pv.o xen_domainbuild.o xen-mapcache.o
 obj-$(CONFIG_NO_XEN) += xen-stub.o
-obj-i386-$(CONFIG_XEN_MAPCACHE) += xen-mapcache.o
-obj-$(CONFIG_NO_XEN_MAPCACHE) += xen-mapcache-stub.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
configure +0 -3
index 7991489..ef4453a 100755
@@ -3329,9 +3329,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
exec.c +7 -7
index 91751c5..dd2faa3 100644
@@ -2923,7 +2923,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
                 abort();
             }
 #else
-            if (xen_mapcache_enabled()) {
+            if (xen_enabled()) {
                 xen_ram_alloc(new_block->offset, size);
             } else {
                 new_block->host = qemu_vmalloc(size);
@@ -2989,7 +2989,7 @@ void qemu_ram_free(ram_addr_t addr)
 #if defined(TARGET_S390X) && defined(CONFIG_KVM)
                 munmap(block->host, block->length);
 #else
-                if (xen_mapcache_enabled()) {
+                if (xen_enabled()) {
                     xen_invalidate_map_cache_entry(block->host);
                 } else {
                     qemu_vfree(block->host);
@@ -3082,7 +3082,7 @@ void *qemu_get_ram_ptr(ram_addr_t addr)
                 QLIST_REMOVE(block, next);
                 QLIST_INSERT_HEAD(&ram_list.blocks, block, next);
             }
-            if (xen_mapcache_enabled()) {
+            if (xen_enabled()) {
                 /* We need to check if the requested address is in the RAM
                  * because we don't want to map the entire memory in QEMU.
                  */
@@ -3111,7 +3111,7 @@ void *qemu_safe_ram_ptr(ram_addr_t addr)
 
     QLIST_FOREACH(block, &ram_list.blocks, next) {
         if (addr - block->offset < block->length) {
-            if (xen_mapcache_enabled()) {
+            if (xen_enabled()) {
                 /* We need to check if the requested address is in the RAM
                  * because we don't want to map the entire memory in QEMU.
                  */
@@ -3135,7 +3135,7 @@ void qemu_put_ram_ptr(void *addr)
 {
     trace_qemu_put_ram_ptr(addr);
 
-    if (xen_mapcache_enabled()) {
+    if (xen_enabled()) {
         RAMBlock *block;
 
         QLIST_FOREACH(block, &ram_list.blocks, next) {
@@ -3168,7 +3168,7 @@ int qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr)
         }
     }
 
-    if (xen_mapcache_enabled()) {
+    if (xen_enabled()) {
         *ram_addr = xen_ram_addr_from_mapcache(ptr);
         return 0;
     }
@@ -4080,7 +4080,7 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
                 access_len -= l;
             }
         }
-        if (xen_mapcache_enabled()) {
+        if (xen_enabled()) {
             uint8_t *buffer1 = buffer;
             uint8_t *end_buffer = buffer + len;
 
hw/xen.h +0 -9
index d435ca0..95029bb 100644
@@ -31,15 +31,6 @@ static inline int xen_enabled(void)
 #endif
 }
 
-static inline int xen_mapcache_enabled(void)
-{
-#ifdef CONFIG_XEN_MAPCACHE
-    return xen_enabled();
-#else
-    return 0;
-#endif
-}
-
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
 void xen_piix3_set_irq(void *opaque, int irq_num, int level);
 void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len);
xen-mapcache-stub.c deleted +0 -49

49 lines not on this page · raw message

xen-stub.c +29 -0
index a4f35a1..d38b41a 100644
@@ -8,6 +8,7 @@
 
 #include "qemu-common.h"
 #include "hw/xen.h"
+#include "xen-mapcache.h"
 
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
 {
@@ -39,3 +40,31 @@ int xen_init(void)
 {
     return -ENOSYS;
 }
+
+uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
+                       uint8_t lock)
+{
+    return NULL;
+}
+
+void xen_map_cache_unlock(void *buffer)
+{
+}
+
+ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
+{
+    return -1;
+}
+
+void xen_invalidate_map_cache_entry(uint8_t *buffer)
+{
+}
+
+uint8_t *xen_map_block(target_phys_addr_t phys_addr, target_phys_addr_t size)
+{
+    return NULL;
+}
+
+void xen_unmap_block(void *addr, ram_addr_t size)
+{
+}
Signature · 1 line
1.7.1
#20 lore raw

Re: [Qemu-devel] [PATCH 4/4] xen: Fold CONFIG_XEN_MAPCACHE into CONFIG_XEN

Quoted 5 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

Xen won't be enabled if there is no backend support available for the host. And that also means the map cache will work. So drop the separate config switch and move the required stubs over to xen-stub.c.

Anthony, Stefano, what was the reason for the separate config option?

Alex

#21 lore raw

Re: [Qemu-devel] [PATCH 4/4] xen: Fold CONFIG_XEN_MAPCACHE into CONFIG_XEN

Quoted 9 lines · Alexander Graf
Quoted 5 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

Xen won't be enabled if there is no backend support available for the host. And that also means the map cache will work. So drop the separate config switch and move the required stubs over to xen-stub.c.

Anthony, Stefano, what was the reason for the separate config option?

Even though I think it is nice to be able to completely disable the mapcache from a compile time option, in practice we don't use it and we don't even have it in qemu-xen.
Also I am pretty sure that disabling the mapcache at the moment would prevent qemu from working on xen completely.
So I think it is OK to remove the option.

#22 lore raw
In reply to Jan Kiszka
Quoted 6 lines · Jan Kiszka

I came across some Xen oddities I couldn't help to clean up. These patches
- simplify the build
- remove a win32 breakage from xen-mapcache.h
- move the map cache functions out of the generic name space

thanks for the patches, cleanups are always welcome :)

#23 lore raw
In reply to Jan Kiszka
Quoted 5 lines · Jan Kiszka

I came across some Xen oddities I couldn't help to clean up. These patches
- simplify the build
- remove a win32 breakage from xen-mapcache.h
- move the map cache functions out of the generic name space

Patches 2-4 don't apply. Please rebase against xen-next at:

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

Alex

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel