On Sun, Jul 17, 2011 at 06:39, Alexander Graf <ag...@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 <ag...@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.per...@citrix.com>
--
Anthony PERARD
