libxl: don't break the build on Xen>=4.5 because of libxl_vcpu_setaffinity()
PATCH 1/1 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.
--- src/libxl/libxl_conf.h | 11 +++++++++++ 1 file changed, 11 insertions(+)
src/libxl/libxl_conf.h +11 -0
@@ -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 ;
Quoted 8 lines · Dario Faggioli
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_AFFINITYis 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
Quoted 34 lines
Signed-off-by Dario Faggioli <[email protected]>Cc Jim Fehlig <[email protected]>Cc Ian Campbell <[email protected]>Cc Ian Jackson <[email protected]>--- src/libxl/libxl_conf.h | 11 +++++++++++ 1 file changed, 11 insertions(+)src/libxl/libxl_conf.h +11
-0@@ -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 ;
Quoted 5 lines · Jim Fehlig
Quoted 4 lines · Dario Faggioli
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.
Quoted 8 lines
Quoted 4 lines
To mark such change, the macro
LIBXL_HAVE_VCPUINFO_SOFT_AFFINITYis 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.
Signature · 2 lines
Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Quoted 13 lines · Eric Blake
Quoted 11 lines · Jim Fehlig
Quoted 9 lines · Dario Faggioli
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_AFFINITYis 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.
Quoted 8 lines
Quoted 4 lines
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
Quoted 7 lines · Jim Fehlig
Quoted 5 lines · Eric Blake
Quoted 4 lines
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.
Quoted 6 lines
Quoted 3 lines
Yes, fixing a build failure is an acceptable fix during hard freeze. Go ahead and push.
Thanks Eric, pushed now.
Cool! Thanks Everyone,
Dario
Signature · 4 lines
<<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)
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
Quoted 8 lines · Dario Faggioli
Quoted 7 lines · Jim Fehlig
Quoted 5 lines · Eric Blake
Quoted 4 lines
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.
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
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.
Quoted 13 lines · Ian Campbell
Quoted 12 lines · Dario Faggioli
Quoted 11 lines · Jim Fehlig
Quoted 8 lines · Eric Blake
Quoted 4 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines
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. :-)
Quoted 3 lines
I've added "does libvirt need a peemptive update?" to my mental checklist for things involved
LIBXL_API_VERSIONchanges.
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
Signature · 4 lines
<<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)
Quoted 3 lines · Dario Faggioli
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
Quoted 8 lines · Jim Fehlig
Quoted 3 lines · Dario Faggioli
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.
Quoted 1 line
Thanks for your work on the push gate Ian!
No problem, glad it's actually flagging useful stuff already!
Ian.