While applying some of the outstanding patches from the masses of Xen patches on the mailing list, I stumbled over a few things and wrote up patches to fix them. Functionally, nothing should change with these applied, but I want to give people the chance to review them before pushing them :). Alexander Graf (3): xen: add mapcache stubs xen: remove CONFIG_XEN_MAPCACHE xen: make xen_enabled even more clever configure | 8 +++++--- hw/xen.h | 2 +- xen-stub.c | 26 ++++++++++++++++++++++++++ 3 files changed, 32 insertions(+), 4 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Alexander Graf
2011-Jul-17 05:39 UTC
[Xen-devel] [PATCH 2/3] xen: remove CONFIG_XEN_MAPCACHE
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Alexander Graf
2011-Jul-17 05:39 UTC
[Xen-devel] [PATCH 3/3] xen: make xen_enabled even more clever
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>
---
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Anthony PERARD
2011-Jul-18 13:52 UTC
[Xen-devel] Re: [Qemu-devel] [PATCH 3/3] xen: make xen_enabled even more clever
On Sun, Jul 17, 2011 at 06:39, Alexander Graf <agraf@suse.de> wrote:> 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> > --- > 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;Cool, better than my fix. Acked-by: Anthony PERARD <anthony.perard@citrix.com> -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sun, 17 Jul 2011, Alexander Graf wrote:> While applying some of the outstanding patches from the masses of Xen patches > on the mailing list, I stumbled over a few things and wrote up patches to fix > them. > > Functionally, nothing should change with these applied, but I want to give > people the chance to review them before pushing them :).They all look all right to me, thanks. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel