[libvirt] [PATCH] libxl: don't break the build on Xen>=4.5 because of libxl_vcpu_setaffinity()
libxl interface for vcpu pinning is changing in Xen 4.5. Basically, libxl_set_vcpuaffinity() now wants one more parameter. That is representative of 'VCPU soft affinity', which libvirt does not use. To mark such change, the macro LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY is defined. Use it as a gate and, if present, re-#define the calls from the old to the new interface, to avoid breaking the build. Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Cc: Jim Fehlig <jfehlig@suse.com> Cc: Ian Campbell <Ian.Campbell@citrix.com> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com> --- src/libxl/libxl_conf.h | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h index 6aa36d2..da66b4e 100644 --- a/src/libxl/libxl_conf.h +++ b/src/libxl/libxl_conf.h @@ -55,6 +55,17 @@ # define LIBXL_DUMP_DIR LIBXL_LIB_DIR "/dump" # define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub" +/* libxl interface for setting VCPU affinity changed in 4.5. In fact, a new + * parameter has been added, representative of 'VCPU soft affinity'. If one + * does not care about it (and that's libvirt case), passing NULL is the + * right thing to do. To mark that change, LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY + * is defined. */ +# ifdef LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY +# define libxl_set_vcpuaffinity(ctx, domid, vcpuid, map) \ + libxl_set_vcpuaffinity((ctx), (domid), (vcpuid), (map), NULL) +# define libxl_set_vcpuaffinity_all(ctx, domid, max_vcpus, map) \ + libxl_set_vcpuaffinity_all((ctx), (domid), (max_vcpus), (map), NULL) +# endif typedef struct _libxlDriverPrivate libxlDriverPrivate; typedef libxlDriverPrivate *libxlDriverPrivatePtr;
Dario Faggioli wrote:
libxl interface for vcpu pinning is changing in Xen 4.5. Basically, libxl_set_vcpuaffinity() now wants one more parameter. That is representative of 'VCPU soft affinity', which libvirt does not use.
To mark such change, the macro LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY is defined. Use it as a gate and, if present, re-#define the calls from the old to the new interface, to avoid breaking the build.
Thanks, looks good. I was about to push, but wanted to check with other libvirt devs first since we are in 1.2.6 freeze. Would it be fine to push this? It fixes a libxl driver build failure against xen-unstable. Regards, Jim
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Cc: Jim Fehlig <jfehlig@suse.com> Cc: Ian Campbell <Ian.Campbell@citrix.com> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com> --- src/libxl/libxl_conf.h | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h index 6aa36d2..da66b4e 100644 --- a/src/libxl/libxl_conf.h +++ b/src/libxl/libxl_conf.h @@ -55,6 +55,17 @@ # define LIBXL_DUMP_DIR LIBXL_LIB_DIR "/dump" # define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"
+/* libxl interface for setting VCPU affinity changed in 4.5. In fact, a new + * parameter has been added, representative of 'VCPU soft affinity'. If one + * does not care about it (and that's libvirt case), passing NULL is the + * right thing to do. To mark that change, LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY + * is defined. */ +# ifdef LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY +# define libxl_set_vcpuaffinity(ctx, domid, vcpuid, map) \ + libxl_set_vcpuaffinity((ctx), (domid), (vcpuid), (map), NULL) +# define libxl_set_vcpuaffinity_all(ctx, domid, max_vcpus, map) \ + libxl_set_vcpuaffinity_all((ctx), (domid), (max_vcpus), (map), NULL) +# endif
typedef struct _libxlDriverPrivate libxlDriverPrivate; typedef libxlDriverPrivate *libxlDriverPrivatePtr;
On 06/30/2014 03:11 PM, Jim Fehlig wrote:
Dario Faggioli wrote:
libxl interface for vcpu pinning is changing in Xen 4.5. Basically, libxl_set_vcpuaffinity() now wants one more parameter. That is representative of 'VCPU soft affinity', which libvirt does not use.
To mark such change, the macro LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY is defined. Use it as a gate and, if present, re-#define the calls from the old to the new interface, to avoid breaking the build.
Thanks, looks good. I was about to push, but wanted to check with other libvirt devs first since we are in 1.2.6 freeze. Would it be fine to push this? It fixes a libxl driver build failure against xen-unstable.
Yes, fixing a build failure is an acceptable fix during hard freeze. Go ahead and push. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Eric Blake wrote:
On 06/30/2014 03:11 PM, Jim Fehlig wrote:
Dario Faggioli wrote:
libxl interface for vcpu pinning is changing in Xen 4.5. Basically, libxl_set_vcpuaffinity() now wants one more parameter. That is representative of 'VCPU soft affinity', which libvirt does not use.
To mark such change, the macro LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY is defined. Use it as a gate and, if present, re-#define the calls from the old to the new interface, to avoid breaking the build.
Thanks, looks good. I was about to push, but wanted to check with other libvirt devs first since we are in 1.2.6 freeze. Would it be fine to push this? It fixes a libxl driver build failure against xen-unstable.
Yes, fixing a build failure is an acceptable fix during hard freeze. Go ahead and push.
Thanks Eric, pushed now. Regards, Jim
On lun, 2014-06-30 at 15:32 -0600, Jim Fehlig wrote:
Eric Blake wrote:
Thanks, looks good. I was about to push, but wanted to check with other libvirt devs first since we are in 1.2.6 freeze. Would it be fine to push this? It fixes a libxl driver build failure against xen-unstable.
Yes, fixing a build failure is an acceptable fix during hard freeze. Go ahead and push.
Thanks Eric, pushed now.
Cool! Thanks Everyone, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
On Tue, 2014-07-01 at 08:52 +0200, Dario Faggioli wrote:
On lun, 2014-06-30 at 15:32 -0600, Jim Fehlig wrote:
Eric Blake wrote:
Thanks, looks good. I was about to push, but wanted to check with other libvirt devs first since we are in 1.2.6 freeze. Would it be fine to push this? It fixes a libxl driver build failure against xen-unstable.
Yes, fixing a build failure is an acceptable fix during hard freeze. Go ahead and push.
Thanks Eric, pushed now.
Cool! Thanks Everyone,
And thanks Dario for the quick fix. WRT Xen's automated testing the new libvirt should get tested today and the result be picked up for a xen-unstable run shortly after, so staging ought to be unblocked by ~tomorrow, barring any other failures. I've added "does libvirt need a peemptive update?" to my mental checklist for things involved LIBXL_API_VERSION changes. Cheers, Ian.
On mar, 2014-07-01 at 09:01 +0100, Ian Campbell wrote:
On Tue, 2014-07-01 at 08:52 +0200, Dario Faggioli wrote:
On lun, 2014-06-30 at 15:32 -0600, Jim Fehlig wrote:
Eric Blake wrote:
Thanks, looks good. I was about to push, but wanted to check with other libvirt devs first since we are in 1.2.6 freeze. Would it be fine to push this? It fixes a libxl driver build failure against xen-unstable.
Yes, fixing a build failure is an acceptable fix during hard freeze. Go ahead and push.
Thanks Eric, pushed now.
Cool! Thanks Everyone,
And thanks Dario for the quick fix.
Well, it could (and should!) have been quicker, but it collapsed with an update of the test box I devote to Xen+libvirt hack/testing... I've added "keep that box in a more good shape" to my menta checklist. :-)
I've added "does libvirt need a peemptive update?" to my mental checklist for things involved LIBXL_API_VERSION changes.
Me too, and actually, looking at things from this perspective, I think the push gate did a good job _as_it_is_ in highlighting how much careful we should be with the libxl interface, and that things either get fixed quickly or changes be reverted. Just thinking out loud here but, if we did not get the push failure, when would have we discovered this? Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
Dario Faggioli wrote:
Just thinking out loud here but, if we did not get the push failure, when would have we discovered this?
Good question. I could have been days (or even weeks) before I stumbled across it. ATM, I don't have any automated builds of libvirt.git master against xen.git master :-/. Adding it to my list... Thanks for your work on the push gate Ian! Regards, Jim
On Tue, 2014-07-01 at 11:00 -0600, Jim Fehlig wrote:
Dario Faggioli wrote:
Just thinking out loud here but, if we did not get the push failure, when would have we discovered this?
Good question. I could have been days (or even weeks) before I stumbled across it. ATM, I don't have any automated builds of libvirt.git master against xen.git master :-/. Adding it to my list...
FWIW I think this effectively already exists in the osstest flights. [xen-unstable test] is testing new Xen against gated libvirt [libvirt test] is testing new libvirt against gated Xen-unstable (where "gated X" means the last successfully tested version of X from the other flight) What's not tested is newest Xen against newest libvirt, but I think any issue should show up in one or the other of the existing flights.
Thanks for your work on the push gate Ian!
No problem, glad it's actually flagging useful stuff already! Ian.
participants (4)
-
Dario Faggioli -
Eric Blake -
Ian Campbell -
Jim Fehlig