Mailing List Archive

[PULL 0/1] xen queue 2020-08-03
The following changes since commit 45a150aa2b3492acf6691c7bdbeb25a8545d8345:

Merge remote-tracking branch 'remotes/ericb/tags/pull-bitmaps-2020-08-03' into staging (2020-08-03 15:13:49 +0100)

are available in the Git repository at:

https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git tags/pull-xen-20200803

for you to fetch changes up to b3fcc98f391e9a60a369d825333b852871cf67b0:

accel/xen: Fix xen_enabled() behavior on target-agnostic objects (2020-08-03 17:39:38 +0100)

----------------------------------------------------------------
xen patches

bug fix

----------------------------------------------------------------
Philippe Mathieu-Daudé (1):
accel/xen: Fix xen_enabled() behavior on target-agnostic objects

include/sysemu/xen.h | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
Re: [PULL 0/1] xen queue 2020-08-03 [ In reply to ]
On Mon, 3 Aug 2020 at 17:53, Anthony PERARD <anthony.perard@citrix.com> wrote:
> ----------------------------------------------------------------
> xen patches
>
> bug fix
>
> ----------------------------------------------------------------
> Philippe Mathieu-Daudé (1):
> accel/xen: Fix xen_enabled() behavior on target-agnostic objects

This fails to compile, all hosts :-(

LINK avr-softmmu/qemu-system-avr
../migration/savevm.o: In function `qemu_loadvm_section_start_full':
/home/petmay01/linaro/qemu-for-merges/migration/savevm.c:2320:
undefined reference to `xen_enabled'
collect2: error: ld returned 1 exit status
[ditto other softmmu link attempts]

Similar but different on OSX:

LINK aarch64-softmmu/qemu-system-aarch64
Undefined symbols for architecture x86_64:
"_xen_enabled", referenced from:
_msix_is_masked in msix.o
_msix_write_config in msix.o
_msix_handle_mask_update in msix.o
_msix_init in msix.o
_msix_notify in msix.o
_msix_reset in msix.o
_msix_set_vector_notifiers in msix.o
...
ld: symbol(s) not found for architecture x86_64

Fails in all the BSD VM builds as well, so I don't think this
is related to incremental vs from-clean builds.

I think the failure here is only on builds where
CONFIG_XEN is not set by configure (which for my merge
build setup appears to be all of them, I think).
In that case when we build a target-agnostic object
it gets an external reference to the xen_enabled()
function, but because Xen is disabled we don't compile
accel/xen/ and so there is no actual implementation of
the function in the link.

This doesn't happen for KVM because there the
CONFIG_KVM_IS_POSSIBLE version of kvm_enabled()
is a #define:
#define kvm_enabled() (kvm_allowed)
and we provide both the "real" version of the
'bool kvm_allowed' in accel/kvm/kvm-all.c and also
the stub version in accel/stubs/kvm-stub.c which will
be used in configurations thta don't build accel/kvm.

I think then that the fix for this build failure is to
either:
(1) add a stub version of xen_allowed() to accel/stubs/xen-stub.c
(which would always return false)

(2) follow KVM more closely, and have xen_allowed() be
a #define to (xen_allowed), with a (non-static)
bool xen_allowed in accel/xen/xen-all.c and another
one in accel/stubs/xen-stub.c

thanks
-- PMM