* Re: [Qemu-devel] [Xen-devel] [PATCH v1] xen: preserve COMPAT in CFLAGS
2018-10-26 10:10 [Qemu-devel] [PATCH v1] xen: preserve COMPAT in CFLAGS Olaf Hering
@ 2018-12-11 9:24 ` Olaf Hering
2018-12-13 11:05 ` [Qemu-devel] " Anthony PERARD
2019-01-21 16:16 ` Anthony PERARD
2 siblings, 0 replies; 6+ messages in thread
From: Olaf Hering @ 2018-12-11 9:24 UTC (permalink / raw)
To: qemu-devel; +Cc: Anthony Perard, open list:X86, Stefano Stabellini
[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]
Ping?
On Fri, Oct 26, Olaf Hering wrote:
> A given Qemu version can not predict what version of Xen it will run on.
> There are some checks in configure to decide what Xen libraries and
> functions are available. How exactly these functions must be accessed
> has to be decided by configure and the user who is compiling Qemu.
> In no way some random header file must override this decision.
>
> Remove the breakage introduced by commit 5eeb39c24b, which would always
> hide the libxc interfaces the given version of Qemu knows about.
>
> The current symptom of such breakage is a build failure with qemu-2.9
> and older, in combination with Xen 4.12.
>
> Fixes: 5eeb39c24b7d4da5d129bfdd9c4fd21cfb3d28d6
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> ---
> include/hw/xen/xen_common.h | 9 ---------
> 1 file changed, 9 deletions(-)
>
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 5f1402b494..33fa2d3497 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -1,15 +1,6 @@
> #ifndef QEMU_HW_XEN_COMMON_H
> #define QEMU_HW_XEN_COMMON_H
>
> -/*
> - * If we have new enough libxenctrl then we do not want/need these compat
> - * interfaces, despite what the user supplied cflags might say. They
> - * must be undefined before including xenctrl.h
> - */
> -#undef XC_WANT_COMPAT_EVTCHN_API
> -#undef XC_WANT_COMPAT_GNTTAB_API
> -#undef XC_WANT_COMPAT_MAP_FOREIGN_API
> -
> #include <xenctrl.h>
> #include <xenstore.h>
> #include <xen/io/xenbus.h>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH v1] xen: preserve COMPAT in CFLAGS
2018-10-26 10:10 [Qemu-devel] [PATCH v1] xen: preserve COMPAT in CFLAGS Olaf Hering
2018-12-11 9:24 ` [Qemu-devel] [Xen-devel] " Olaf Hering
@ 2018-12-13 11:05 ` Anthony PERARD
2019-01-07 14:20 ` Olaf Hering
2019-01-21 16:16 ` Anthony PERARD
2 siblings, 1 reply; 6+ messages in thread
From: Anthony PERARD @ 2018-12-13 11:05 UTC (permalink / raw)
To: Olaf Hering, Ian Jackson; +Cc: qemu-devel, Stefano Stabellini, open list:X86
Hi,
Ian, we have those XC_WANT_COMPAT_* #defines to allow consumers of Xen
libs be able to use old interfaces. Do you think it's a good idea to
have this consumers (QEMU here) #undef the flag when it has implemented
the newer interface?
I guess the issue we have here is that when libxc interface are
re-implemented into a xen libs, the meaning of XC_WANT_COMPAT_* flags is
changed. And the QEMU fails to build even with the flags supplied in
cflags.
There is another thread that Olaf have started here:
<20181025140808.13eefc21.olaf@aepfle.de>
https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg01950.html
On Fri, Oct 26, 2018 at 12:10:16PM +0200, Olaf Hering wrote:
> A given Qemu version can not predict what version of Xen it will run on.
> There are some checks in configure to decide what Xen libraries and
> functions are available. How exactly these functions must be accessed
> has to be decided by configure and the user who is compiling Qemu.
> In no way some random header file must override this decision.
>
> Remove the breakage introduced by commit 5eeb39c24b, which would always
> hide the libxc interfaces the given version of Qemu knows about.
>
> The current symptom of such breakage is a build failure with qemu-2.9
> and older, in combination with Xen 4.12.
>
> Fixes: 5eeb39c24b7d4da5d129bfdd9c4fd21cfb3d28d6
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> ---
> include/hw/xen/xen_common.h | 9 ---------
> 1 file changed, 9 deletions(-)
>
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 5f1402b494..33fa2d3497 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -1,15 +1,6 @@
> #ifndef QEMU_HW_XEN_COMMON_H
> #define QEMU_HW_XEN_COMMON_H
>
> -/*
> - * If we have new enough libxenctrl then we do not want/need these compat
> - * interfaces, despite what the user supplied cflags might say. They
> - * must be undefined before including xenctrl.h
> - */
> -#undef XC_WANT_COMPAT_EVTCHN_API
> -#undef XC_WANT_COMPAT_GNTTAB_API
> -#undef XC_WANT_COMPAT_MAP_FOREIGN_API
> -
> #include <xenctrl.h>
> #include <xenstore.h>
> #include <xen/io/xenbus.h>
--
Anthony PERARD
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH v1] xen: preserve COMPAT in CFLAGS
2018-12-13 11:05 ` [Qemu-devel] " Anthony PERARD
@ 2019-01-07 14:20 ` Olaf Hering
0 siblings, 0 replies; 6+ messages in thread
From: Olaf Hering @ 2019-01-07 14:20 UTC (permalink / raw)
To: Anthony PERARD; +Cc: Ian Jackson, qemu-devel, Stefano Stabellini, open list:X86
[-- Attachment #1: Type: text/plain, Size: 612 bytes --]
Am Thu, 13 Dec 2018 11:05:25 +0000
schrieb Anthony PERARD <anthony.perard@citrix.com>:
> Hi,
>
> Ian, we have those XC_WANT_COMPAT_* #defines to allow consumers of Xen
> libs be able to use old interfaces. Do you think it's a good idea to
> have this consumers (QEMU here) #undef the flag when it has implemented
> the newer interface?
I think the wording is wrong.
The defines exist to expose existing APIs to software that was not updated to use the "latest" API. To me it looks like the undef's are wrong. Even the usage in configure looks bogus, but that is another unrelated thing.
Olaf
[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH v1] xen: preserve COMPAT in CFLAGS
2018-10-26 10:10 [Qemu-devel] [PATCH v1] xen: preserve COMPAT in CFLAGS Olaf Hering
2018-12-11 9:24 ` [Qemu-devel] [Xen-devel] " Olaf Hering
2018-12-13 11:05 ` [Qemu-devel] " Anthony PERARD
@ 2019-01-21 16:16 ` Anthony PERARD
2019-01-21 17:23 ` Anthony PERARD
2 siblings, 1 reply; 6+ messages in thread
From: Anthony PERARD @ 2019-01-21 16:16 UTC (permalink / raw)
To: Olaf Hering; +Cc: qemu-devel, Stefano Stabellini, open list:X86
On Fri, Oct 26, 2018 at 12:10:16PM +0200, Olaf Hering wrote:
> A given Qemu version can not predict what version of Xen it will run on.
> There are some checks in configure to decide what Xen libraries and
> functions are available. How exactly these functions must be accessed
> has to be decided by configure and the user who is compiling Qemu.
> In no way some random header file must override this decision.
>
> Remove the breakage introduced by commit 5eeb39c24b, which would always
> hide the libxc interfaces the given version of Qemu knows about.
>
> The current symptom of such breakage is a build failure with qemu-2.9
> and older, in combination with Xen 4.12.
I can't reproduce this build issue.
I've build QEMU 2.9.1 against Xen 4.11, and it build just fine. (I just
needed -DXC_WANT_COMPAT_DEVICEMODEL_API).
But when building againt unstable (to be 4.12), it's configure that
fails. That patch would not work.
Could you tell me a configuration of QEMU and Xen that fails? Their
versions, or theirs commit id.
And can you attach the output of ./configure, as well as the build
failures?
As for https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg01950.html
It appear that the same QEMU 2.9.1 is used, but QEMU isn't supposed to
use the function xc_map_foreign_bulk when built against Xen 4.12. That
function is only supposed to be used when building against Xen 4.6 and
earlier. QEMU 2.9.1 knows about Xen up to 4.8, it should have used
xenforeignmemory_map directly. So, this is probably an issue with
./configure.
Thanks,
--
Anthony PERARD
^ permalink raw reply [flat|nested] 6+ messages in thread