[Qemu-devel] hax_enabled() cannot be called in vl.c

[Peter Maydell <peter.maydell@linaro.org>]

In vl.c we do this:

    if (hax_enabled()) {
        hax_sync_vcpus();
    }

But hax_enabled() varies depending on CONFIG_HAX: if that is
not defined then it is "#define hax_enabled() (0)", otherwise
it is a function. And CONFIG_HAX is a per-target configuration
define, only set for i386-softmmu and x86_64-softmmu.

Unfortunately, Makefile.objs puts vl.o in common-obj-y, meaning it
is built once and used for each target. So we can't use anything
here that has a target-specific definition.


My guess is that this is why this travis job has failed:
 https://travis-ci.org/qemu/qemu/jobs/463302115

Undefined symbols for architecture x86_64:
  "_hax_enabled", referenced from:
      _qemu_main in vl.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [qemu-system-m68k] Error 1

(though it is a little odd that it has only just happened,
given that the code has been this way for some time AFAIK;
this may be a new config at the Travis end or a new target
we added to our Travis config.)


I'm not sure what the best fix is here -- perhaps following
how xen_enabled() works, where it is always defined as an
(inline) function which returns the xen_allowed bool.

kvm_enabled() does a similar thing to what hax_enabled() does,
but this works out OK because it takes care to avoid
providing the #define-to-0 implementation except in the
case where it is building a target-specific file for a
target where KVM is not enabled; for common files it
will provide the function prototype which will end up
linking to a stub implementation. So we could handle hax
like that too.

thanks
-- PMM