[xen-unstable bisection] complete build-i386-libvirt

[xen-unstable bisection] complete build-i386-libvirt

[xen.org]

branch xen-unstable
xen branch xen-unstable
job build-i386-libvirt
test libvirt-build

Tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  871b43a309d80ac99458c13c2c3da8d15c482d30
  Bug not present: 6cc89d3101d8874e01a69a89a65736a2adfbd199


  commit 871b43a309d80ac99458c13c2c3da8d15c482d30
  Author: Dario Faggioli <dario.faggioli@citrix.com>
  Date:   Fri Jun 20 18:19:12 2014 +0200
  
      libxl: get and set soft affinity
      
      Make space a new cpumap in vcpu_info, called cpumap_soft,
      for retrieving soft affinity, and amend the relevant API
      accordingly.
      
      libxl_set_vcpuaffinity() now takes two cpumaps, one for hard
      and one for soft affinity (LIBXL_API_VERSION is exploited to
      retain source level backword compatibility). Either of the
      two cpumap can be NULL, in which case, only the affinity
      corresponding to the non-NULL cpumap will be affected.
      
      Getting soft affinity happens indirectly (see, e.g.,
      `xl vcpu-list'), as it is already for hard affinity).
      
      This commit also introduces some logic to check whether the
      affinity which will be used by Xen to schedule the vCPU(s)
      does actually match with the cpumaps provided. In fact, we
      want to allow every possible combination of hard and soft
      affinity to be set, but we warn the user upon particularly
      weird situations (e.g., hard and soft being disjoint sets
      of pCPUs).
      
      This very change also update the error handling for calls
      to libxl_set_vcpuaffinity() in xl, as that can now be any
      libxl error code, not just only -1.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
      Acked-by: Ian Campbell <ian.campbell@citrix.com>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-i386-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 27580 fail [host=rice-weevil] / 27481 [host=bush-cricket] 27467 ok.
Failure / basis pass flights: 27580 / 27467
(tree with no url: seabios)
Tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git
Latest fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c d0395cc49b2ec6d1723c01f1daf2394b9264ca29 7d9251f642047974d206b04638ca098917980302 012098b81b82e550410f4b9d04029c3dc81ea253
Basis pass fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c 7f5b3c338e0f8938ba575dec18255dcbee0c2ee2 7d9251f642047974d206b04638ca098917980302 ddb4aa5dfa13781e8f31ba20923c14c1a083ce83
Generating revisions with ./adhoc-revtuple-generator  git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]#fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2-fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 git://xenbits.xen.org/libvirt.git#48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c-48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c git://xenbits.xen.org/staging/qemu-xen-unstable.git#7f5b3c338e0f8938ba575dec18255dcbee0c2ee2-d0395cc49b2ec6d1723c01f1daf2394b9264ca29 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#7d9251f642047974d206b04638ca098917980302-7d9251f642047974d206b04638ca098917980302 git://xenbits.xen.org/xen.git#ddb4aa5dfa13781e8f31ba20923c14c1a083ce83-012098b81b82e550410f4b9d04029c3dc81ea253
Cloning into bare repository /export/home/osstest/repos/qemu-xen-unstable...
Cloning into bare repository /export/home/osstest/repos/xen...
Cloning into bare repository /export/home/osstest/repos/qemu-xen-unstable...
Cloning into bare repository /export/home/osstest/repos/xen...
Loaded 2003 nodes in revision graph
Searching for test results:
 27467 pass fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c 7f5b3c338e0f8938ba575dec18255dcbee0c2ee2 7d9251f642047974d206b04638ca098917980302 ddb4aa5dfa13781e8f31ba20923c14c1a083ce83
 27481 [host=bush-cricket]
 27580 fail fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c d0395cc49b2ec6d1723c01f1daf2394b9264ca29 7d9251f642047974d206b04638ca098917980302 012098b81b82e550410f4b9d04029c3dc81ea253
 27792 pass fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c 7f5b3c338e0f8938ba575dec18255dcbee0c2ee2 7d9251f642047974d206b04638ca098917980302 ddb4aa5dfa13781e8f31ba20923c14c1a083ce83
 27798 fail fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c d0395cc49b2ec6d1723c01f1daf2394b9264ca29 7d9251f642047974d206b04638ca098917980302 012098b81b82e550410f4b9d04029c3dc81ea253
 27799 fail fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c d0395cc49b2ec6d1723c01f1daf2394b9264ca29 7d9251f642047974d206b04638ca098917980302 49a37237c78816937595082775e505bb8b18ea39
 27801 pass fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c d0395cc49b2ec6d1723c01f1daf2394b9264ca29 7d9251f642047974d206b04638ca098917980302 6cc89d3101d8874e01a69a89a65736a2adfbd199
 27802 fail fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c d0395cc49b2ec6d1723c01f1daf2394b9264ca29 7d9251f642047974d206b04638ca098917980302 549a29fcd81ff10783e6c9bce93255218fed79fb
 27803 fail fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c d0395cc49b2ec6d1723c01f1daf2394b9264ca29 7d9251f642047974d206b04638ca098917980302 a5dbdcf6743ac032b53df645e2aab6251d667923
 27804 fail fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c d0395cc49b2ec6d1723c01f1daf2394b9264ca29 7d9251f642047974d206b04638ca098917980302 871b43a309d80ac99458c13c2c3da8d15c482d30
 27805 pass fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c d0395cc49b2ec6d1723c01f1daf2394b9264ca29 7d9251f642047974d206b04638ca098917980302 6cc89d3101d8874e01a69a89a65736a2adfbd199
 27806 fail fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c d0395cc49b2ec6d1723c01f1daf2394b9264ca29 7d9251f642047974d206b04638ca098917980302 871b43a309d80ac99458c13c2c3da8d15c482d30
 27807 pass fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c d0395cc49b2ec6d1723c01f1daf2394b9264ca29 7d9251f642047974d206b04638ca098917980302 6cc89d3101d8874e01a69a89a65736a2adfbd199
 27809 fail fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c d0395cc49b2ec6d1723c01f1daf2394b9264ca29 7d9251f642047974d206b04638ca098917980302 871b43a309d80ac99458c13c2c3da8d15c482d30
Searching for interesting versions
 Result found: flight 27467 (pass), for basis pass
 Result found: flight 27580 (fail), for basis failure
 Repro found: flight 27792 (pass), for basis pass
 Repro found: flight 27798 (fail), for basis failure
 0 revisions at fdf9a5de25e265b41bccde64e93c1a2e13b3fdd2 48d81cef3b2dff6fe02bd7c8f0bf4f5aff917d8c d0395cc49b2ec6d1723c01f1daf2394b9264ca29 7d9251f642047974d206b04638ca098917980302 6cc89d3101d8874e01a69a89a65736a2adfbd199
No revisions left to test, checking graph state.
 Result found: flight 27801 (pass), for last pass
 Result found: flight 27804 (fail), for first failure
 Repro found: flight 27805 (pass), for last pass
 Repro found: flight 27806 (fail), for first failure
 Repro found: flight 27807 (pass), for last pass
 Repro found: flight 27809 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  871b43a309d80ac99458c13c2c3da8d15c482d30
  Bug not present: 6cc89d3101d8874e01a69a89a65736a2adfbd199

Cloning into bare repository /export/home/osstest/repos/xen...

  commit 871b43a309d80ac99458c13c2c3da8d15c482d30
  Author: Dario Faggioli <dario.faggioli@citrix.com>
  Date:   Fri Jun 20 18:19:12 2014 +0200
  
      libxl: get and set soft affinity
      
      Make space a new cpumap in vcpu_info, called cpumap_soft,
      for retrieving soft affinity, and amend the relevant API
      accordingly.
      
      libxl_set_vcpuaffinity() now takes two cpumaps, one for hard
      and one for soft affinity (LIBXL_API_VERSION is exploited to
      retain source level backword compatibility). Either of the
      two cpumap can be NULL, in which case, only the affinity
      corresponding to the non-NULL cpumap will be affected.
      
      Getting soft affinity happens indirectly (see, e.g.,
      `xl vcpu-list'), as it is already for hard affinity).
      
      This commit also introduces some logic to check whether the
      affinity which will be used by Xen to schedule the vCPU(s)
      does actually match with the cpumaps provided. In fact, we
      want to allow every possible combination of hard and soft
      affinity to be set, but we warn the user upon particularly
      weird situations (e.g., hard and soft being disjoint sets
      of pCPUs).
      
      This very change also update the error handling for calls
      to libxl_set_vcpuaffinity() in xl, as that can now be any
      libxl error code, not just only -1.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
      Acked-by: Ian Campbell <ian.campbell@citrix.com>

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-i386-libvirt.libvirt-build.{dot,ps,png,html}.
----------------------------------------
27809: tolerable ALL FAIL

flight 27809 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/27809/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-i386-libvirt            5 libvirt-build           fail baseline untested


jobs:
 build-i386-libvirt                                           fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

Re: [xen-unstable bisection] complete build-i386-libvirt

[Ian Campbell]

On Sun, 2014-06-29 at 18:35 +0100, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job build-i386-libvirt
> test libvirt-build
> 
> Tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
> Tree: libvirt git://xenbits.xen.org/libvirt.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen git://xenbits.xen.org/xen.git
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen git://xenbits.xen.org/xen.git
>   Bug introduced:  871b43a309d80ac99458c13c2c3da8d15c482d30
>   Bug not present: 6cc89d3101d8874e01a69a89a65736a2adfbd199
> 
> 
>   commit 871b43a309d80ac99458c13c2c3da8d15c482d30
>   Author: Dario Faggioli <dario.faggioli@citrix.com>
>   Date:   Fri Jun 20 18:19:12 2014 +0200
>   
>       libxl: get and set soft affinity

Dario,

libvirt doesn't use the LIBXL_API_VERSION mechanism but instead uses the
LIBXL_HAVE stuff to retain compatibility.

Will you be able to send a patch against libvirt today to make it use
the new interface (conditional on LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY)?

Ian.

Re: [xen-unstable bisection] complete build-i386-libvirt

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1671 bytes --]

On lun, 2014-06-30 at 08:11 +0100, Ian Campbell wrote:
> On Sun, 2014-06-29 at 18:35 +0100, xen.org wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job build-i386-libvirt
> > test libvirt-build
> > 
> > Tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
> > Tree: libvirt git://xenbits.xen.org/libvirt.git
> > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> > Tree: xen git://xenbits.xen.org/xen.git
> > 
> > *** Found and reproduced problem changeset ***
> > 
> >   Bug is in tree:  xen git://xenbits.xen.org/xen.git
> >   Bug introduced:  871b43a309d80ac99458c13c2c3da8d15c482d30
> >   Bug not present: 6cc89d3101d8874e01a69a89a65736a2adfbd199
> > 
> > 
> >   commit 871b43a309d80ac99458c13c2c3da8d15c482d30
> >   Author: Dario Faggioli <dario.faggioli@citrix.com>
> >   Date:   Fri Jun 20 18:19:12 2014 +0200
> >   
> >       libxl: get and set soft affinity
> 
> Dario,
> 
> libvirt doesn't use the LIBXL_API_VERSION mechanism but instead uses the
> LIBXL_HAVE stuff to retain compatibility.
> 
Ah, I see.

> Will you be able to send a patch against libvirt today to make it use
> the new interface (conditional on LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY)?
> 
Sure thing! Thanks for pointing this out to me.

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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [libvirt] [Xen-devel] [xen-unstable bisection] complete build-i386-libvirt

[Dario Faggioli]

[-- Attachment #1.1.1: Type: text/plain, Size: 2984 bytes --]

On lun, 2014-06-30 at 08:11 +0100, Ian Campbell wrote:
> On Sun, 2014-06-29 at 18:35 +0100, xen.org wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job build-i386-libvirt
> > test libvirt-build
> > 
> > Tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
> > Tree: libvirt git://xenbits.xen.org/libvirt.git
> > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> > Tree: xen git://xenbits.xen.org/xen.git
> > 
> > *** Found and reproduced problem changeset ***
> > 
> >   Bug is in tree:  xen git://xenbits.xen.org/xen.git
> >   Bug introduced:  871b43a309d80ac99458c13c2c3da8d15c482d30
> >   Bug not present: 6cc89d3101d8874e01a69a89a65736a2adfbd199
> > 
> > 
> >   commit 871b43a309d80ac99458c13c2c3da8d15c482d30
> >   Author: Dario Faggioli <dario.faggioli@citrix.com>
> >   Date:   Fri Jun 20 18:19:12 2014 +0200
> >   
> >       libxl: get and set soft affinity
> 
> Dario,
> 
> libvirt doesn't use the LIBXL_API_VERSION mechanism but instead uses the
> LIBXL_HAVE stuff to retain compatibility.
> 
> Will you be able to send a patch against libvirt today to make it use
> the new interface (conditional on LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY)?
> 
So, brief recap for the ones not knowing the details of this, libxl
interface for vcpu pinning is changing (basically,
libxl_set_vcpuaffinity() wants one more param).

Libxl provides some ifdefs for these situations, and in this case, the
gate to be used is, as Ian is saying:

#ifdef LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY

One possible approach is to enclose all the calls into such
#ifdef-#endif but, although there are only two of them right now, I
don't like it (what if we need more calls in the future?).

I could come up with the alternatives attached to this message. In
patch1, I use the new interface in the code and #define it to the old
one if !LIBXL_HAV_VCPUINFO_SOFT_AFFINITY. In patch2 I do the opposite
(keep old interface in the code and redefine to new, with additional
param equal to NULL).

I like patch1 better, but I think it can cause "unused variable" like
warnings if, at some point in future, we will actually use the new soft
affinity parameter, when compiling on a version of libxl that does not
define HAVE_VCPUINFO_SOFT_AFFINITY, can't it? If yes, is it an issue? If
yes, a big enough one to make us prefer patch2?

Just let me know your thoughts, and I'll submit the one you prefer
appropriately.

Regards,
Dario

PS. patches not tested, I'm updating my xen+libvirt testbox. Will be
able to test soon (for sure within today)

-- 
<<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)


[-- Attachment #1.1.2: patch1 --]
[-- Type: text/x-patch, Size: 2068 bytes --]

diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index 6aa36d2..6449b46 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_conf.h
@@ -55,6 +55,13 @@
 # define LIBXL_DUMP_DIR LIBXL_LIB_DIR "/dump"
 # define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"
 
+# ifndef LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY
+#  define libxl_set_vcpuaffinity(ctx, domid, vcpuid, map, softmap) \
+    libxl_set_vcpuaffinity((ctx), (domid), (vcpuid), (map))
+#  define libxl_set_vcpuaffinity_all(ctx, domid, max_vcpus, map, softmap) \
+    libxl_set_vcpuaffinity_all((ctx), (domid), (max_vcpus), (map))
+# endif
+
 
 typedef struct _libxlDriverPrivate libxlDriverPrivate;
 typedef libxlDriverPrivate *libxlDriverPrivatePtr;
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index da3f241..fafd9c5 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -1029,7 +1029,7 @@ libxlDomainSetVcpuAffinities(libxlDriverPrivatePtr driver, virDomainObjPtr vm)
         map.size = cpumaplen;
         map.map = cpumap;
 
-        if (libxl_set_vcpuaffinity(priv->ctx, def->id, vcpu, &map) != 0) {
+        if (libxl_set_vcpuaffinity(priv->ctx, def->id, vcpu, &map, NULL) != 0) {
             virReportError(VIR_ERR_INTERNAL_ERROR,
                            _("Failed to pin vcpu '%d' with libxenlight"), vcpu);
             goto cleanup;
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 646c9b9..6f4a2f2 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -1981,7 +1981,8 @@ libxlDomainPinVcpuFlags(virDomainPtr dom, unsigned int vcpu,
         libxlDomainObjPrivatePtr priv;
 
         priv = vm->privateData;
-        if (libxl_set_vcpuaffinity(priv->ctx, vm->def->id, vcpu, &map) != 0) {
+        if (libxl_set_vcpuaffinity(priv->ctx, vm->def->id,
+                                   vcpu, &map, NULL) != 0) {
             virReportError(VIR_ERR_INTERNAL_ERROR,
                            _("Failed to pin vcpu '%d' with libxenlight"),
                            vcpu);

[-- Attachment #1.1.3: patch2 --]
[-- Type: text/x-patch, Size: 718 bytes --]

diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index 6aa36d2..164b578 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_conf.h
@@ -55,6 +55,13 @@
 # define LIBXL_DUMP_DIR LIBXL_LIB_DIR "/dump"
 # define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"
 
+# 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;

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [xen-unstable bisection] complete build-i386-libvirt

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable bisection] complete build-i386-libvirt"):
> libvirt doesn't use the LIBXL_API_VERSION mechanism but instead uses the
> LIBXL_HAVE stuff to retain compatibility.

This means that either:

 (a) Anyone who makes a backwards-incompatible[1] change to the libxl
     API must ensure that the corresponding libvirt change is in the
     libvirt tree and through its osstest push gate before the libxl
     change is committed;

or

 (b) We need to stop gating xen.git pushes on libvirt.

[1] Of course if you use LIBXL_API_VERSION there is no such thing as a
backwards-incompatible change.  I mean an change that breaks
non-VERSION using callers.

Neither (a) nor (b) is particularly palatable.

Perhaps we can avoid this by having the libvirt builds #define
LIBXL_API_VERSION but only some of the time.  As a configure option
perhaps.  (The configure option would specify not the version to use,
but rather just that VERSION ought to be defined rather than not.)

We could supply that option in the osstest push gates for things that
aren't libvirt.

Ian.

Re: [xen-unstable bisection] complete build-i386-libvirt

[Ian Campbell]

On Mon, 2014-06-30 at 15:13 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable bisection] complete build-i386-libvirt"):
> > libvirt doesn't use the LIBXL_API_VERSION mechanism but instead uses the
> > LIBXL_HAVE stuff to retain compatibility.
> 
> This means that either:
> 
>  (a) Anyone who makes a backwards-incompatible[1] change to the libxl
>      API must ensure that the corresponding libvirt change is in the
>      libvirt tree and through its osstest push gate before the libxl
>      change is committed;
> 
> or
> 
>  (b) We need to stop gating xen.git pushes on libvirt.
> 
> [1] Of course if you use LIBXL_API_VERSION there is no such thing as a
> backwards-incompatible change.  I mean an change that breaks
> non-VERSION using callers.
> 
> Neither (a) nor (b) is particularly palatable.
> 
> Perhaps we can avoid this by having the libvirt builds #define
> LIBXL_API_VERSION but only some of the time.  As a configure option
> perhaps.  (The configure option would specify not the version to use,
> but rather just that VERSION ought to be defined rather than not.)

We could probably arrange for this ourselves in the harness, using
whatever CFLAGS-appending scheme the libvirt build system supports.

However we currently insist that LIBXL_API_VERSION is one of a known
bunch of values if it is set, so defining it without a specific value
won't currently work.

What is the intended semantics of setting it to nothing? Latest or
oldest interface? I'm not sure how either would help -- it seems to me
we'd need a Do What I Need option ;-) I think specifically it would need
to be the latest version of Xen that libvirt currently knows how to deal
with, which seems tricky to arrange in general.

Another wrinkle is that like SONAMES we only currently bump
LIBXL_API_VERSION once per release cycle (if at all).

> 
> We could supply that option in the osstest push gates for things that
> aren't libvirt.
> 
> Ian.

Re: [xen-unstable bisection] complete build-i386-libvirt

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable bisection] complete build-i386-libvirt"):
> On Mon, 2014-06-30 at 15:13 +0100, Ian Jackson wrote:
> > Perhaps we can avoid this by having the libvirt builds #define
> > LIBXL_API_VERSION but only some of the time.  As a configure option
> > perhaps.  (The configure option would specify not the version to use,
> > but rather just that VERSION ought to be defined rather than not.)
> 
> We could probably arrange for this ourselves in the harness, using
> whatever CFLAGS-appending scheme the libvirt build system supports.

Then we would have to choose the version which would be wrong.  The
actual version to define or not ought to be along with the libvirt
code in its git reepo.

> However we currently insist that LIBXL_API_VERSION is one of a known
> bunch of values if it is set, so defining it without a specific value
> won't currently work.

That's not what I mean.

I mean that libvirt would offer a configure option whose meaning would
be "please define LIBXL_API_VERSION to whatever the latest version is
that you support".

> Another wrinkle is that like SONAMES we only currently bump
> LIBXL_API_VERSION once per release cycle (if at all).

That would be easy to do differently.  We don't make changes like this
all that often and they already involve a lot of palaver.

Ian.

Re: [xen-unstable bisection] complete build-i386-libvirt

[Ian Campbell]

On Mon, 2014-06-30 at 15:36 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable bisection] complete build-i386-libvirt"):
> > On Mon, 2014-06-30 at 15:13 +0100, Ian Jackson wrote:
> > > Perhaps we can avoid this by having the libvirt builds #define
> > > LIBXL_API_VERSION but only some of the time.  As a configure option
> > > perhaps.  (The configure option would specify not the version to use,
> > > but rather just that VERSION ought to be defined rather than not.)
> > 
> > We could probably arrange for this ourselves in the harness, using
> > whatever CFLAGS-appending scheme the libvirt build system supports.
> 
> Then we would have to choose the version which would be wrong.  The
> actual version to define or not ought to be along with the libvirt
> code in its git reepo.
> 
> > However we currently insist that LIBXL_API_VERSION is one of a known
> > bunch of values if it is set, so defining it without a specific value
> > won't currently work.
> 
> That's not what I mean.
> 
> I mean that libvirt would offer a configure option whose meaning would
> be "please define LIBXL_API_VERSION to whatever the latest version is
> that you support".

OIC, yes I suppose that might work. I have a feeling folks on the
libvirt side might not be so keen though. Copying Jim.

Oh wait. If libvirt supports up to e.g. Xen 4.4 today then this option
would cause it to #define LIBXL_API_VERSION to that. But Xen 4.2 and 4.3
libxl wouldn't know what to do with it and would bail out.

We could deploy this flag only on the xen-unstable flights on the
assumption that this is the only place where the libxl API ought to be
changing.

> > Another wrinkle is that like SONAMES we only currently bump
> > LIBXL_API_VERSION once per release cycle (if at all).
> 
> That would be easy to do differently.  We don't make changes like this
> all that often and they already involve a lot of palaver.
> 
> Ian.

Re: [xen-unstable bisection] complete build-i386-libvirt

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable bisection] complete build-i386-libvirt"):
> Oh wait. If libvirt supports up to e.g. Xen 4.4 today then this option
> would cause it to #define LIBXL_API_VERSION to that. But Xen 4.2 and 4.3
> libxl wouldn't know what to do with it and would bail out.

Yes.

> We could deploy this flag only on the xen-unstable flights on the
> assumption that this is the only place where the libxl API ought to be
> changing.

Indeed.

Ian.

Re: [libvirt] [Xen-devel] [xen-unstable bisection] complete build-i386-libvirt

[Jim Fehlig]

Dario Faggioli wrote:
> On lun, 2014-06-30 at 08:11 +0100, Ian Campbell wrote:
>   
>> On Sun, 2014-06-29 at 18:35 +0100, xen.org wrote:
>>     
>>> branch xen-unstable
>>> xen branch xen-unstable
>>> job build-i386-libvirt
>>> test libvirt-build
>>>
>>> Tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
>>> Tree: libvirt git://xenbits.xen.org/libvirt.git
>>> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
>>> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
>>> Tree: xen git://xenbits.xen.org/xen.git
>>>
>>> *** Found and reproduced problem changeset ***
>>>
>>>   Bug is in tree:  xen git://xenbits.xen.org/xen.git
>>>   Bug introduced:  871b43a309d80ac99458c13c2c3da8d15c482d30
>>>   Bug not present: 6cc89d3101d8874e01a69a89a65736a2adfbd199
>>>
>>>
>>>   commit 871b43a309d80ac99458c13c2c3da8d15c482d30
>>>   Author: Dario Faggioli <dario.faggioli@citrix.com>
>>>   Date:   Fri Jun 20 18:19:12 2014 +0200
>>>   
>>>       libxl: get and set soft affinity
>>>       
>> Dario,
>>
>> libvirt doesn't use the LIBXL_API_VERSION mechanism but instead uses the
>> LIBXL_HAVE stuff to retain compatibility.
>>
>> Will you be able to send a patch against libvirt today to make it use
>> the new interface (conditional on LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY)?
>>
>>     
> So, brief recap for the ones not knowing the details of this, libxl
> interface for vcpu pinning is changing (basically,
> libxl_set_vcpuaffinity() wants one more param).
>
> Libxl provides some ifdefs for these situations, and in this case, the
> gate to be used is, as Ian is saying:
>
> #ifdef LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY
>
> One possible approach is to enclose all the calls into such
> #ifdef-#endif but, although there are only two of them right now, I
> don't like it (what if we need more calls in the future?).
>
> I could come up with the alternatives attached to this message. In
> patch1, I use the new interface in the code and #define it to the old
> one if !LIBXL_HAV_VCPUINFO_SOFT_AFFINITY. In patch2 I do the opposite
> (keep old interface in the code and redefine to new, with additional
> param equal to NULL).
>   

Patch2 is more along the lines of current practice wrt LIBXL_HAVE_.

> I like patch1 better, but I think it can cause "unused variable" like
> warnings if, at some point in future, we will actually use the new soft
> affinity parameter, when compiling on a version of libxl that does not
> define HAVE_VCPUINFO_SOFT_AFFINITY, can't it?

Yes.

> If yes, is it an issue?

As you say, only when the new parameter is actually used.  But that will
cause build failures when warnings are treated as errors.

> If yes, a big enough one to make us prefer patch2?
>   

Yes, I think so.  And as mentioned above, it is similar to how other
LIBXL_HAVE_ is handled.

Regards,
Jim

Re: [libvirt] [Xen-devel] [xen-unstable bisection] complete build-i386-libvirt

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1110 bytes --]

On lun, 2014-06-30 at 11:14 -0600, Jim Fehlig wrote:
> Dario Faggioli wrote:
> > 
> > I like patch1 better, but I think it can cause "unused variable" like
> > warnings if, at some point in future, we will actually use the new soft
> > affinity parameter, when compiling on a version of libxl that does not
> > define HAVE_VCPUINFO_SOFT_AFFINITY, can't it?
> 
> Yes.
> 
> > If yes, is it an issue?
> 
> As you say, only when the new parameter is actually used.  But that will
> cause build failures when warnings are treated as errors.
> 
> > If yes, a big enough one to make us prefer patch2?
> >   
> 
> Yes, I think so.  And as mentioned above, it is similar to how other
> LIBXL_HAVE_ is handled.
> 
Patch2 it is then:

 http://lists.xen.org/archives/html/xen-devel/2014-06/msg03930.html

Thanks and 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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [xen-unstable bisection] complete build-i386-libvirt

[Ian Campbell]

On Mon, 2014-06-30 at 16:21 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable bisection] complete build-i386-libvirt"):
> > Oh wait. If libvirt supports up to e.g. Xen 4.4 today then this option
> > would cause it to #define LIBXL_API_VERSION to that. But Xen 4.2 and 4.3
> > libxl wouldn't know what to do with it and would bail out.
> 
> Yes.
> 
> > We could deploy this flag only on the xen-unstable flights on the
> > assumption that this is the only place where the libxl API ought to be
> > changing.
> 
> Indeed.

I'd be a bit concerned that unless it was used in some "normal" scenario
this option would itself bit rot and we'd end up back where we started.

We can't just turn it on for the libvirt flight too, can we? I think
that would defeat the purpose (by causing Xen to rewind to the interface
which libvirt wants rather than the latest in order to provoke
breakage).

We could make the build-*-libvirt jobs build twice, once with and once
without. Perhaps in the libvirt flight only. Would that work?

Jim, do you think the idea of an option of this kind will fly at all
with you and the libvirt maintainers?

Perhaps something like:
        /* Force libxl to supply the latest API which we know about.
        This 
         * must be updated  whenever adding code which uses LIBXL_HAVE_*
         */
        #ifdef VIR_LIBXL_FORCE_LATEST_SUPPORTED_API
        #define LIBXL_API_VERSION 0x405000
        #endif
        
        #include <libxl.h>

Then osstest could CFLAGS=-DVIR_LIBXL_FORCE_LATEST_SUPPORTED_API when
configuring etc.

Ian.

Re: [xen-unstable bisection] complete build-i386-libvirt

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1332 bytes --]

On mar, 2014-07-01 at 09:09 +0100, Ian Campbell wrote:
> On Mon, 2014-06-30 at 16:21 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable bisection] complete build-i386-libvirt"):
> > > Oh wait. If libvirt supports up to e.g. Xen 4.4 today then this option
> > > would cause it to #define LIBXL_API_VERSION to that. But Xen 4.2 and 4.3
> > > libxl wouldn't know what to do with it and would bail out.
> > 
> > Yes.
> > 
> > > We could deploy this flag only on the xen-unstable flights on the
> > > assumption that this is the only place where the libxl API ought to be
> > > changing.
> > 
> > Indeed.

> We could make the build-*-libvirt jobs build twice, once with and once
> without. Perhaps in the libvirt flight only. Would that work?
> 
+1

If going for the LIBXL_API_VERSION compile option way, I like this idea
of building twice a lot.

It avoids unnecessarily holding a push but, at the same time, let us
know libvirt requires attention. It means a bit more of time, but not
that much, I think.

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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel