xen: preserve COMPAT in CFLAGS
PATCH 1/1 xen: preserve COMPAT in CFLAGS
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.
--- include/hw/xen/xen_common.h | 9 --------- 1 file changed, 9 deletions(-)
include/hw/xen/xen_common.h +0 -9
@@ -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>
Ping?
Quoted 39 lines · Olaf Hering
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 5eeb39c24b7d4da5d129bfdd9c4fd21cfb3d28d6Signed-off-by Olaf Hering <[email protected]>--- include/hw/xen/xen_common.h | 9 --------- 1 file changed, 9 deletions(-)include/hw/xen/xen_common.h +0
-9@@ -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>
Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Ping?
Quoted 43 lines · Olaf Hering
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 5eeb39c24b7d4da5d129bfdd9c4fd21cfb3d28d6Signed-off-by Olaf Hering <[email protected]>--- include/hw/xen/xen_common.h | 9 --------- 1 file changed, 9 deletions(-)include/hw/xen/xen_common.h +0
-9@@ -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
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
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:
<[email protected]>
https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg01950.html
Quoted 38 lines · Olaf Hering
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 5eeb39c24b7d4da5d129bfdd9c4fd21cfb3d28d6Signed-off-by Olaf Hering <[email protected]>--- include/hw/xen/xen_common.h | 9 --------- 1 file changed, 9 deletions(-)include/hw/xen/xen_common.h +0
-9@@ -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>
Signature · 6 lines
Anthony PERARD _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Am Thu, 13 Dec 2018 11:05:25 +0000
schrieb Anthony PERARD <[email protected]>:
Quoted 6 lines
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
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Quoted 11 lines · Olaf Hering
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,
Signature · 6 lines
Anthony PERARD _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Quoted 7 lines · Anthony PERARD
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 functionxc_map_foreign_bulkwhen 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 usedxenforeignmemory_mapdirectly. So, this is probably an issue with ./configure.
You may want to backport that patch:
https://lists.nongnu.org/archive/html/qemu-devel/2019-01/msg05074.html
That should help with building older version of QEMU against Xen 4.12 and newer.
Signature · 1 line
Anthony PERARD