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>
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
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
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
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
On Mon, Jan 21, 2019 at 04:16:35PM +0000, Anthony PERARD wrote: > 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. 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. -- Anthony PERARD
© 2016 - 2025 Red Hat, Inc.