[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

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

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-i386-libvirt
testid libvirt-build

Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.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:  66dd1c62b2a3c707bd5c55750d10a8223fbd577f
  Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/172100/


  commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
  Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
  Date:   Fri Jul 15 22:20:24 2022 +0300
  
      libxl: Add support for Virtio disk configuration
      
      This patch adds basic support for configuring and assisting virtio-mmio
      based virtio-disk backend (emulator) which is intended to run out of
      Qemu and could be run in any domain.
      Although the Virtio block device is quite different from traditional
      Xen PV block device (vbd) from the toolstack's point of view:
       - as the frontend is virtio-blk which is not a Xenbus driver, nothing
         written to Xenstore are fetched by the frontend currently ("vdev"
         is not passed to the frontend). But this might need to be revised
         in future, so frontend data might be written to Xenstore in order to
         support hotplugging virtio devices or passing the backend domain id
         on arch where the device-tree is not available.
       - the ring-ref/event-channel are not used for the backend<->frontend
         communication, the proposed IPC for Virtio is IOREQ/DM
      it is still a "block device" and ought to be integrated in existing
      "disk" handling. So, re-use (and adapt) "disk" parsing/configuration
      logic to deal with Virtio devices as well.
      
      For the immediate purpose and an ability to extend that support for
      other use-cases in future (Qemu, virtio-pci, etc) perform the following
      actions:
      - Add new disk backend type (LIBXL_DISK_BACKEND_STANDALONE) and reflect
        that in the configuration
      - Introduce new disk "specification" and "transport" fields to struct
        libxl_device_disk. Both are written to the Xenstore. The transport
        field is only used for the specification "virtio" and it assumes
        only "mmio" value for now.
      - Introduce new "specification" option with "xen" communication
        protocol being default value.
      - Add new device kind (LIBXL__DEVICE_KIND_VIRTIO_DISK) as current
        one (LIBXL__DEVICE_KIND_VBD) doesn't fit into Virtio disk model
      
      An example of domain configuration for Virtio disk:
      disk = [ 'phy:/dev/mmcblk0p3, xvda1, backendtype=standalone, specification=virtio']
      
      Nothing has changed for default Xen disk configuration.
      
      Please note, this patch is not enough for virtio-disk to work
      on Xen (Arm), as for every Virtio device (including disk) we need
      to allocate Virtio MMIO params (IRQ and memory region) and pass
      them to the backend, also update Guest device-tree. The subsequent
      patch will add these missing bits. For the current patch,
      the default "irq" and "base" are just written to the Xenstore.
      This is not an ideal splitting, but this way we avoid breaking
      the bisectability.
      
      Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
      Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
      Acked-by: George Dunlap <george.dunlap@citrix.com>
      Tested-by: Jiamei Xie <jiamei.xie@arm.com>


For bisection revision-tuple graph see:
   http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/build-i386-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable/build-i386-libvirt.libvirt-build --summary-out=tmp/172100.bisection-summary --basis-template=172073 --blessings=real,real-bisect,real-retry xen-unstable build-i386-libvirt libvirt-build
Searching for failure / basis pass:
 172081 fail [host=huxelrebe0] / 172073 [host=nobling0] 172058 [host=nocera0] 171993 [host=albana0] 171910 [host=nocera0] 171896 [host=albana0] 171887 [host=italia1] 171873 [host=italia1] 171862 [host=albana0] 171859 [host=nobling1] 171856 ok.
Failure / basis pass flights: 172081 / 171856
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 ca45d3cb4586372909f350e54482246f994e1bc7
Basis pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f1c719d5cd8ab4d5d4c8df139b9df3c2c47221d1
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/libvirt.git#2c846fa6bcc11929c9fb857a22430fb9945654ad-2c846fa6bcc11929c9fb857a22430fb9945654ad https://gitlab.com/keycodemap/keycodemapdb.git#27acf0ef828bf719b2053ba398b195829413dbdd-27acf0ef828bf719b2053ba398b195829413dbdd git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c7437ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 git://xenbits.xen.org/qemu-xen.git#b746458e1ce1bec85e58b458386f8b7a0bedf\
 aa6-b746458e1ce1bec85e58b458386f8b7a0bedfaa6 git://xenbits.xen.org/xen.git#f1c719d5cd8ab4d5d4c8df139b9df3c2c47221d1-ca45d3cb4586372909f350e54482246f994e1bc7
Loaded 5001 nodes in revision graph
Searching for test results:
 171856 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f1c719d5cd8ab4d5d4c8df139b9df3c2c47221d1
 171859 [host=nobling1]
 171862 [host=albana0]
 171873 [host=italia1]
 171887 [host=italia1]
 171896 [host=albana0]
 171910 [host=nocera0]
 171933 []
 171993 [host=albana0]
 172058 [host=nocera0]
 172073 [host=nobling0]
 172081 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 ca45d3cb4586372909f350e54482246f994e1bc7
 172088 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f1c719d5cd8ab4d5d4c8df139b9df3c2c47221d1
 172090 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 ca45d3cb4586372909f350e54482246f994e1bc7
 172092 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 13316827faadbb4f72ae6c625af9938d8f976f86
 172094 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f732240fd3bac25116151db5ddeb7203b62e85ce
 172096 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
 172097 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f732240fd3bac25116151db5ddeb7203b62e85ce
 172098 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
 172099 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f732240fd3bac25116151db5ddeb7203b62e85ce
 172100 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
Searching for interesting versions
 Result found: flight 171856 (pass), for basis pass
 For basis failure, parent search stopping at 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f732240fd3bac25116151db5ddeb7203b62e85ce, results HASH(0x5607da348ab8) HASH(0x5607da340470) HASH(0x5607da336480) For basis failure, parent search stopping at 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1\
 ce1bec85e58b458386f8b7a0bedfaa6 13316827faadbb4f72ae6c625af9938d8f976f86, results HASH(0x5607da346ab0) For basis failure, parent search stopping at 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f1c719d5cd8ab4d5d4c8df139b9df3c2c47221d1, results HASH(0x5607da33d0c0) HASH(0x5607da339b30) Result found: flight 172081 (fail), for basis failure (at ancestor ~368)
 Repro found: flight 172088 (pass), for basis pass
 Repro found: flight 172090 (fail), for basis failure
 0 revisions at 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f732240fd3bac25116151db5ddeb7203b62e85ce
No revisions left to test, checking graph state.
 Result found: flight 172094 (pass), for last pass
 Result found: flight 172096 (fail), for first failure
 Repro found: flight 172097 (pass), for last pass
 Repro found: flight 172098 (fail), for first failure
 Repro found: flight 172099 (pass), for last pass
 Repro found: flight 172100 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  66dd1c62b2a3c707bd5c55750d10a8223fbd577f
  Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/172100/


  commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
  Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
  Date:   Fri Jul 15 22:20:24 2022 +0300
  
      libxl: Add support for Virtio disk configuration
      
      This patch adds basic support for configuring and assisting virtio-mmio
      based virtio-disk backend (emulator) which is intended to run out of
      Qemu and could be run in any domain.
      Although the Virtio block device is quite different from traditional
      Xen PV block device (vbd) from the toolstack's point of view:
       - as the frontend is virtio-blk which is not a Xenbus driver, nothing
         written to Xenstore are fetched by the frontend currently ("vdev"
         is not passed to the frontend). But this might need to be revised
         in future, so frontend data might be written to Xenstore in order to
         support hotplugging virtio devices or passing the backend domain id
         on arch where the device-tree is not available.
       - the ring-ref/event-channel are not used for the backend<->frontend
         communication, the proposed IPC for Virtio is IOREQ/DM
      it is still a "block device" and ought to be integrated in existing
      "disk" handling. So, re-use (and adapt) "disk" parsing/configuration
      logic to deal with Virtio devices as well.
      
      For the immediate purpose and an ability to extend that support for
      other use-cases in future (Qemu, virtio-pci, etc) perform the following
      actions:
      - Add new disk backend type (LIBXL_DISK_BACKEND_STANDALONE) and reflect
        that in the configuration
      - Introduce new disk "specification" and "transport" fields to struct
        libxl_device_disk. Both are written to the Xenstore. The transport
        field is only used for the specification "virtio" and it assumes
        only "mmio" value for now.
      - Introduce new "specification" option with "xen" communication
        protocol being default value.
      - Add new device kind (LIBXL__DEVICE_KIND_VIRTIO_DISK) as current
        one (LIBXL__DEVICE_KIND_VBD) doesn't fit into Virtio disk model
      
      An example of domain configuration for Virtio disk:
      disk = [ 'phy:/dev/mmcblk0p3, xvda1, backendtype=standalone, specification=virtio']
      
      Nothing has changed for default Xen disk configuration.
      
      Please note, this patch is not enough for virtio-disk to work
      on Xen (Arm), as for every Virtio device (including disk) we need
      to allocate Virtio MMIO params (IRQ and memory region) and pass
      them to the backend, also update Guest device-tree. The subsequent
      patch will add these missing bits. For the current patch,
      the default "irq" and "base" are just written to the Xenstore.
      This is not an ideal splitting, but this way we avoid breaking
      the bisectability.
      
      Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
      Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
      Acked-by: George Dunlap <george.dunlap@citrix.com>
      Tested-by: Jiamei Xie <jiamei.xie@arm.com>

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

flight 172100 xen-unstable real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/172100/

Failures :-/ but no regressions.

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


jobs:
 build-i386-libvirt                                           fail    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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

[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:  gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
  Bug introduced:  b9bfe78424b871f5b92e5ee9e7d21ef951a6801d
  Bug not present: bd86632bd0a614a4195e38ae376893432fcaec3b


  commit b9bfe78424b871f5b92e5ee9e7d21ef951a6801d
  Author: Paul Eggert <eggert@cs.ucla.edu>
  Date:   Thu Jan 1 01:38:23 2015 +0000
  
      version-etc: new year
      
      * doc/gnulib.texi:
      * lib/version-etc.c (COPYRIGHT_YEAR): Update copyright date.
      * all files: Run 'make update-copyright'.


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:
 32902 fail [host=field-cricket] / 32877 [host=bush-cricket] 32669 ok.
Failure / basis pass flights: 32902 / 32669
(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 b9bfe78424b871f5b92e5ee9e7d21ef951a6801d 2360fe5d24175835d3f5fd1c7e8e6e13addab629 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 16518d9ed8f25d3e53931dd1aa343072933e4604 2360fe5d24175835d3f5fd1c7e8e6e13addab629 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Generating revisions with ./adhoc-revtuple-generator  git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]#16518d9ed8f25d3e53931dd1aa343072933e4604-b9bfe78424b871f5b92e5ee9e7d21ef951a6801d git://xenbits.xen.org/libvirt.git#2360fe5d24175835d3f5fd1c7e8e6e13addab629-2360fe5d24175835d3f5fd1c7e8e6e13addab629 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#1ebb75b1fee779621b63e84fefa7b07354c43a99-1ebb75b1fee779621b63e84fefa7b07354c43a99 git://xenbits.xen.org/xen.git#36174af3fbeb1b662c0eadbfa193e77f68cc955b-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/gnulib
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/gnulib
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 1001 nodes in revision graph
Searching for test results:
 32594 [host=bush-cricket]
 32612 [host=grain-weevil]
 32669 pass 16518d9ed8f25d3e53931dd1aa343072933e4604 2360fe5d24175835d3f5fd1c7e8e6e13addab629 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32877 [host=bush-cricket]
 32902 fail b9bfe78424b871f5b92e5ee9e7d21ef951a6801d 2360fe5d24175835d3f5fd1c7e8e6e13addab629 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32927 pass 16518d9ed8f25d3e53931dd1aa343072933e4604 2360fe5d24175835d3f5fd1c7e8e6e13addab629 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32932 fail b9bfe78424b871f5b92e5ee9e7d21ef951a6801d 2360fe5d24175835d3f5fd1c7e8e6e13addab629 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32933 pass 55cda57aa2efe89cee367f73fb4b0ce55a1c8c18 2360fe5d24175835d3f5fd1c7e8e6e13addab629 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32934 pass b8db7e8831439a93d234077da228844115bcc8a2 2360fe5d24175835d3f5fd1c7e8e6e13addab629 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32936 pass bd86632bd0a614a4195e38ae376893432fcaec3b 2360fe5d24175835d3f5fd1c7e8e6e13addab629 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32938 fail b9bfe78424b871f5b92e5ee9e7d21ef951a6801d 2360fe5d24175835d3f5fd1c7e8e6e13addab629 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32939 pass bd86632bd0a614a4195e38ae376893432fcaec3b 2360fe5d24175835d3f5fd1c7e8e6e13addab629 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32940 fail b9bfe78424b871f5b92e5ee9e7d21ef951a6801d 2360fe5d24175835d3f5fd1c7e8e6e13addab629 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32941 pass bd86632bd0a614a4195e38ae376893432fcaec3b 2360fe5d24175835d3f5fd1c7e8e6e13addab629 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32942 fail b9bfe78424b871f5b92e5ee9e7d21ef951a6801d 2360fe5d24175835d3f5fd1c7e8e6e13addab629 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Searching for interesting versions
 Result found: flight 32669 (pass), for basis pass
 Result found: flight 32902 (fail), for basis failure
 Repro found: flight 32927 (pass), for basis pass
 Repro found: flight 32932 (fail), for basis failure
 0 revisions at bd86632bd0a614a4195e38ae376893432fcaec3b 2360fe5d24175835d3f5fd1c7e8e6e13addab629 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
No revisions left to test, checking graph state.
 Result found: flight 32936 (pass), for last pass
 Result found: flight 32938 (fail), for first failure
 Repro found: flight 32939 (pass), for last pass
 Repro found: flight 32940 (fail), for first failure
 Repro found: flight 32941 (pass), for last pass
 Repro found: flight 32942 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
  Bug introduced:  b9bfe78424b871f5b92e5ee9e7d21ef951a6801d
  Bug not present: bd86632bd0a614a4195e38ae376893432fcaec3b

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/gnulib
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit b9bfe78424b871f5b92e5ee9e7d21ef951a6801d
  Author: Paul Eggert <eggert@cs.ucla.edu>
  Date:   Thu Jan 1 01:38:23 2015 +0000
  
      version-etc: new year
      
      * doc/gnulib.texi:
      * lib/version-etc.c (COPYRIGHT_YEAR): Update copyright date.
      * all files: Run 'make update-copyright'.

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

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

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