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

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

[Peter Maydell]

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

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

[Paolo Bonzini]

On 04/12/18 15:45, Peter Maydell wrote:
> 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.

Yes, the KVM one is the correct way to do it.  The #define-to-0
implementation is used so that the compiler can optimize out more code,
the function acts as a fallback.

Paolo

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

[Thomas Huth]

On 2018-12-04 15:45, Peter Maydell wrote:
> 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.

I guess we should add CONFIG_HAX to include/exec/poison.h, just like
CONFIG_KVM can already be found there...?

 Thomas