[Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm

[Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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:  aacc143006429de46932aabae17c13846c71fa45
  Bug not present: 2572c7d76e1aee9b11a23c548cee69b15a35401f
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/146234/


  commit aacc143006429de46932aabae17c13846c71fa45
  Author: Andrew Cooper <andrew.cooper3@citrix.com>
  Date:   Thu Jan 2 21:37:36 2020 +0000
  
      tools/libxl: Plumb domain_create_state down into libxl__build_pre()
      
      To fix CPUID handling, libxl__build_pre() is going to have to distinguish
      between a brand new VM vs one which is being migrated-in/resumed.
      
      No functional change.
      
      Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>


For bisection revision-tuple graph see:
   http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.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/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install --summary-out=tmp/146234.bisection-summary --basis-template=146058 --blessings=real,real-bisect xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
 146205 fail [host=albana1] / 146119 [host=pinot1] 146094 [host=rimava1] 146050 [host=italia0] 146039 [host=debina1] 146030 [host=godello0] 146018 [host=albana0] 146006 [host=elbling1] 145982 [host=chardonnay0] 145955 [host=pinot1] 145903 [host=huxelrebe1] 145879 [host=huxelrebe0] 145851 [host=chardonnay1] 145826 [host=pinot0] 145796 [host=fiano0] 145773 [host=elbling0] 145749 ok.
Failure / basis pass flights: 146205 / 145749
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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 b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 97f10daf5f4bac91db732ef45c562839686f2c04
Basis pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef f383de87a2fb077f1fdbd4594493af613b15c233
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#b98aebd298246df37b472c52a2ee1023256d02e3-b98aebd298246df37b472c52a2ee1023256d02e3 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e41\
 0bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef git://xenbits.xen.org/xen.git#f383de87a2fb077f1fdbd4594493af613b15c233-97f10daf5f4bac91db732ef45c562839686f2c04
Loaded 5001 nodes in revision graph
Searching for test results:
 145749 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef f383de87a2fb077f1fdbd4594493af613b15c233
 145773 [host=elbling0]
 145796 [host=fiano0]
 145826 [host=pinot0]
 145851 [host=chardonnay1]
 145879 [host=huxelrebe0]
 145903 [host=huxelrebe1]
 145955 [host=pinot1]
 146006 [host=elbling1]
 145982 [host=chardonnay0]
 146030 [host=godello0]
 146018 [host=albana0]
 146039 [host=debina1]
 146050 [host=italia0]
 146094 [host=rimava1]
 146205 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 97f10daf5f4bac91db732ef45c562839686f2c04
 146119 [host=pinot1]
 146206 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef f383de87a2fb077f1fdbd4594493af613b15c233
 146176 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 97f10daf5f4bac91db732ef45c562839686f2c04
 146234 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef aacc143006429de46932aabae17c13846c71fa45
 146215 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 97f10daf5f4bac91db732ef45c562839686f2c04
 146217 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef ba322a175059a712802401e8337c6c7952b265d1
 146219 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 8d1d28bfcfd04d15c07c2f5c63aed3c7d220b024
 146220 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef b663b30c21466b919046cfc0187f086df19e0368
 146222 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef dda31ce9521c3b6a7750076f79427be77dea9b5b
 146226 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef aacc143006429de46932aabae17c13846c71fa45
 146227 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 2572c7d76e1aee9b11a23c548cee69b15a35401f
 146229 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef aacc143006429de46932aabae17c13846c71fa45
 146230 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 2572c7d76e1aee9b11a23c548cee69b15a35401f
 146231 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef aacc143006429de46932aabae17c13846c71fa45
 146232 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 2572c7d76e1aee9b11a23c548cee69b15a35401f
Searching for interesting versions
 Result found: flight 145749 (pass), for basis pass
 Result found: flight 146176 (fail), for basis failure
 Repro found: flight 146206 (pass), for basis pass
 Repro found: flight 146215 (fail), for basis failure
 0 revisions at b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 2572c7d76e1aee9b11a23c548cee69b15a35401f
No revisions left to test, checking graph state.
 Result found: flight 146227 (pass), for last pass
 Result found: flight 146229 (fail), for first failure
 Repro found: flight 146230 (pass), for last pass
 Repro found: flight 146231 (fail), for first failure
 Repro found: flight 146232 (pass), for last pass
 Repro found: flight 146234 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  aacc143006429de46932aabae17c13846c71fa45
  Bug not present: 2572c7d76e1aee9b11a23c548cee69b15a35401f
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/146234/


  commit aacc143006429de46932aabae17c13846c71fa45
  Author: Andrew Cooper <andrew.cooper3@citrix.com>
  Date:   Thu Jan 2 21:37:36 2020 +0000
  
      tools/libxl: Plumb domain_create_state down into libxl__build_pre()
      
      To fix CPUID handling, libxl__build_pre() is going to have to distinguish
      between a brand new VM vs one which is being migrated-in/resumed.
      
      No functional change.
      
      Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.{dot,ps,png,html,svg}.
----------------------------------------
146234: tolerable ALL FAIL

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

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail baseline untested


jobs:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        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-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm

[Roger Pau Monné]

On Sun, Jan 19, 2020 at 03:17:13AM +0000, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
> testid debian-hvm-install
> 
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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:  aacc143006429de46932aabae17c13846c71fa45
>   Bug not present: 2572c7d76e1aee9b11a23c548cee69b15a35401f
>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/146234/
> 
> 
>   commit aacc143006429de46932aabae17c13846c71fa45
>   Author: Andrew Cooper <andrew.cooper3@citrix.com>
>   Date:   Thu Jan 2 21:37:36 2020 +0000
>   
>       tools/libxl: Plumb domain_create_state down into libxl__build_pre()
>       
>       To fix CPUID handling, libxl__build_pre() is going to have to distinguish
>       between a brand new VM vs one which is being migrated-in/resumed.
>       
>       No functional change.
>       
>       Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>       Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

The issue is that this change is passing the guest domain_create_state
to libxl__domain_build in libxl__spawn_stub_dm, and hence the
stubdomain doesn't get created. I have the following patch that fixes
it, but it's kind of dirty.

---8<---
From 688fde95992d07bb1123d324a68006dd08bc6512 Mon Sep 17 00:00:00 2001
From: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 21 Jan 2020 10:14:09 +0000
Subject: [PATCH] libxl: fix stubdomain creation after aacc143006429de
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

aacc143006429de broke stubdomain creation by passing the guest
domain_create_state to libxl__domain_build in libxl__spawn_stub_dm,
when it should instead be crafting a new domain_create_state for the
stubdomain.

Fixes: aacc143006429de ('tools/libxl: Plumb domain_create_state down into libxl__build_pre()')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 tools/libxl/libxl_dm.c       | 22 +++++++++++++---------
 tools/libxl/libxl_internal.h |  3 +--
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3f08ccad1b..b1ddde77e8 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2110,17 +2110,21 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__domain_create_state *dcs)
     xs_transaction_t t;
 
     /* convenience aliases */
-    libxl_domain_config *const dm_config = &sdss->dm_config;
     libxl_domain_config *const guest_config = sdss->dm.guest_config;
     const int guest_domid = sdss->dm.guest_domid;
     libxl__domain_build_state *const d_state = sdss->dm.build_state;
-    libxl__domain_build_state *const stubdom_state = &sdss->dm_state;
+    libxl__domain_build_state *stubdom_state;
+    libxl_domain_config *dm_config;
 
     /* Initialise private part of sdss */
-    libxl__domain_build_state_init(stubdom_state);
     dmss_init(&sdss->dm);
     dmss_init(&sdss->pvqemu);
     libxl__xswait_init(&sdss->xswait);
+    GCNEW(sdss->dcs);
+    stubdom_state = &sdss->dcs->build_state;
+    libxl__domain_build_state_init(stubdom_state);
+    GCNEW(sdss->dcs->guest_config);
+    dm_config = sdss->dcs->guest_config;
 
     if (guest_config->b_info.device_model_version !=
         LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
@@ -2198,7 +2202,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__domain_create_state *dcs)
     if (ret)
         goto out;
     uint32_t dm_domid = sdss->pvqemu.guest_domid;
-    ret = libxl__domain_build(gc, dm_domid, dcs);
+    ret = libxl__domain_build(gc, dm_domid, sdss->dcs);
     if (ret)
         goto out;
 
@@ -2264,11 +2268,11 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
     libxl__device_console *console;
 
     /* convenience aliases */
-    libxl_domain_config *const dm_config = &sdss->dm_config;
+    libxl_domain_config *const dm_config = sdss->dcs->guest_config;
     libxl_domain_config *const guest_config = sdss->dm.guest_config;
     const int guest_domid = sdss->dm.guest_domid;
     libxl__domain_build_state *const d_state = sdss->dm.build_state;
-    libxl__domain_build_state *const stubdom_state = &sdss->dm_state;
+    libxl__domain_build_state *const stubdom_state = &sdss->dcs->build_state;
     uint32_t dm_domid = sdss->pvqemu.guest_domid;
     int need_qemu;
 
@@ -2354,8 +2358,8 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
 
     sdss->pvqemu.spawn.ao = ao;
     sdss->pvqemu.guest_domid = dm_domid;
-    sdss->pvqemu.guest_config = &sdss->dm_config;
-    sdss->pvqemu.build_state = &sdss->dm_state;
+    sdss->pvqemu.guest_config = sdss->dcs->guest_config;
+    sdss->pvqemu.build_state = &sdss->dcs->build_state;
     sdss->pvqemu.callback = spawn_stubdom_pvqemu_cb;
 
     if (!need_qemu) {
@@ -2464,7 +2468,7 @@ static void stubdom_xswait_cb(libxl__egc *egc, libxl__xswait_state *xswait,
     if (strcmp(p, "running"))
         return;
  out:
-    libxl__domain_build_state_dispose(&sdss->dm_state);
+    libxl__domain_build_state_dispose(&sdss->dcs->build_state);
     libxl__xswait_stop(gc, xswait);
     dmss_dispose(gc, &sdss->dm);
     dmss_dispose(gc, &sdss->pvqemu);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d919f91882..abf88dfd76 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4102,8 +4102,7 @@ typedef struct {
     /* filled in by user, must remain valid: */
     libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->dm,) */
     /* private to libxl__spawn_stub_dm: */
-    libxl_domain_config dm_config;
-    libxl__domain_build_state dm_state;
+    libxl__domain_create_state *dcs;
     libxl__dm_spawn_state pvqemu;
     libxl__destroy_domid_state dis;
     libxl__multidev multidev;
-- 
2.25.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm

[Anthony PERARD]

On Tue, Jan 21, 2020 at 10:21:09AM +0000, Roger Pau Monné wrote:
> The issue is that this change is passing the guest domain_create_state
> to libxl__domain_build in libxl__spawn_stub_dm, and hence the
> stubdomain doesn't get created. I have the following patch that fixes
> it, but it's kind of dirty.
> 
> ---8<---
> From 688fde95992d07bb1123d324a68006dd08bc6512 Mon Sep 17 00:00:00 2001
> From: Roger Pau Monne <roger.pau@citrix.com>
> Date: Tue, 21 Jan 2020 10:14:09 +0000
> Subject: [PATCH] libxl: fix stubdomain creation after aacc143006429de
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8

:-(, this is a lie. The email I've received has a different charset. git
complained about it. Maybe next time the patch could be attached, or it
could be a proper patch with some note (after ---) (git send-email can
do --in-reply-to), or it could be two separated emails with the first
one replying to the report and the second the patch (all in the same
thread).

> Content-Transfer-Encoding: 8bit
> 
> aacc143006429de broke stubdomain creation by passing the guest
> domain_create_state to libxl__domain_build in libxl__spawn_stub_dm,
> when it should instead be crafting a new domain_create_state for the
> stubdomain.
> 
> Fixes: aacc143006429de ('tools/libxl: Plumb domain_create_state down into libxl__build_pre()')
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
>  tools/libxl/libxl_dm.c       | 22 +++++++++++++---------
>  tools/libxl/libxl_internal.h |  3 +--
>  2 files changed, 14 insertions(+), 11 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 3f08ccad1b..b1ddde77e8 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -2110,17 +2110,21 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__domain_create_state *dcs)
>      xs_transaction_t t;
>  
>      /* convenience aliases */
> -    libxl_domain_config *const dm_config = &sdss->dm_config;
>      libxl_domain_config *const guest_config = sdss->dm.guest_config;
>      const int guest_domid = sdss->dm.guest_domid;
>      libxl__domain_build_state *const d_state = sdss->dm.build_state;
> -    libxl__domain_build_state *const stubdom_state = &sdss->dm_state;
> +    libxl__domain_build_state *stubdom_state;
> +    libxl_domain_config *dm_config;
>  
>      /* Initialise private part of sdss */
> -    libxl__domain_build_state_init(stubdom_state);
>      dmss_init(&sdss->dm);
>      dmss_init(&sdss->pvqemu);
>      libxl__xswait_init(&sdss->xswait);
> +    GCNEW(sdss->dcs);
> +    stubdom_state = &sdss->dcs->build_state;
> +    libxl__domain_build_state_init(stubdom_state);
> +    GCNEW(sdss->dcs->guest_config);
> +    dm_config = sdss->dcs->guest_config;

I don't think that's enough, we need to initialize the dcs properly.
Otherwise, libxl__domain_build() might start using thing that aren't set
properly. Maybe we would need a new struct which could be pass to
libxl__domain_build*, or that might be more complicated than needed.

>  
>      if (guest_config->b_info.device_model_version !=
>          LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index d919f91882..abf88dfd76 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -4102,8 +4102,7 @@ typedef struct {
>      /* filled in by user, must remain valid: */
>      libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->dm,) */
>      /* private to libxl__spawn_stub_dm: */
> -    libxl_domain_config dm_config;
> -    libxl__domain_build_state dm_state;
> +    libxl__domain_create_state *dcs;

This should be named dm_dcs, I think, to follow the same pattern as
before.


Thanks for tracking this down.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm

[Roger Pau Monné]

On Thu, Jan 23, 2020 at 03:34:25PM +0000, Anthony PERARD wrote:
> On Tue, Jan 21, 2020 at 10:21:09AM +0000, Roger Pau Monné wrote:
> > The issue is that this change is passing the guest domain_create_state
> > to libxl__domain_build in libxl__spawn_stub_dm, and hence the
> > stubdomain doesn't get created. I have the following patch that fixes
> > it, but it's kind of dirty.
> > 
> > ---8<---
> > From 688fde95992d07bb1123d324a68006dd08bc6512 Mon Sep 17 00:00:00 2001
> > From: Roger Pau Monne <roger.pau@citrix.com>
> > Date: Tue, 21 Jan 2020 10:14:09 +0000
> > Subject: [PATCH] libxl: fix stubdomain creation after aacc143006429de
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> 
> :-(, this is a lie. The email I've received has a different charset.

Really? The email headers also contain the same tag, and hence all my
emails would have a wrong encoding then.

> git
> complained about it. Maybe next time the patch could be attached, or it
> could be a proper patch with some note (after ---) (git send-email can
> do --in-reply-to), or it could be two separated emails with the first
> one replying to the report and the second the patch (all in the same
> thread).

I can certainly send the patch separately as a reply as you say above,
but I would still need to fix my email client to set the proper
encoding then.

> 
> > Content-Transfer-Encoding: 8bit
> > 
> > aacc143006429de broke stubdomain creation by passing the guest
> > domain_create_state to libxl__domain_build in libxl__spawn_stub_dm,
> > when it should instead be crafting a new domain_create_state for the
> > stubdomain.
> > 
> > Fixes: aacc143006429de ('tools/libxl: Plumb domain_create_state down into libxl__build_pre()')
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> >  tools/libxl/libxl_dm.c       | 22 +++++++++++++---------
> >  tools/libxl/libxl_internal.h |  3 +--
> >  2 files changed, 14 insertions(+), 11 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index 3f08ccad1b..b1ddde77e8 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -2110,17 +2110,21 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__domain_create_state *dcs)
> >      xs_transaction_t t;
> >  
> >      /* convenience aliases */
> > -    libxl_domain_config *const dm_config = &sdss->dm_config;
> >      libxl_domain_config *const guest_config = sdss->dm.guest_config;
> >      const int guest_domid = sdss->dm.guest_domid;
> >      libxl__domain_build_state *const d_state = sdss->dm.build_state;
> > -    libxl__domain_build_state *const stubdom_state = &sdss->dm_state;
> > +    libxl__domain_build_state *stubdom_state;
> > +    libxl_domain_config *dm_config;
> >  
> >      /* Initialise private part of sdss */
> > -    libxl__domain_build_state_init(stubdom_state);
> >      dmss_init(&sdss->dm);
> >      dmss_init(&sdss->pvqemu);
> >      libxl__xswait_init(&sdss->xswait);
> > +    GCNEW(sdss->dcs);
> > +    stubdom_state = &sdss->dcs->build_state;
> > +    libxl__domain_build_state_init(stubdom_state);
> > +    GCNEW(sdss->dcs->guest_config);
> > +    dm_config = sdss->dcs->guest_config;
> 
> I don't think that's enough, we need to initialize the dcs properly.
> Otherwise, libxl__domain_build() might start using thing that aren't set
> properly. Maybe we would need a new struct which could be pass to
> libxl__domain_build*, or that might be more complicated than needed.

Er likely yes, but creating a complete domain_create_state for the
stubdom will be very cumbersome I think. Maybe we can copy the one
from the guest over the stubdom one in order to initialize it?

Not sure that's any better than just using an empty one.

> >  
> >      if (guest_config->b_info.device_model_version !=
> >          LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index d919f91882..abf88dfd76 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -4102,8 +4102,7 @@ typedef struct {
> >      /* filled in by user, must remain valid: */
> >      libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->dm,) */
> >      /* private to libxl__spawn_stub_dm: */
> > -    libxl_domain_config dm_config;
> > -    libxl__domain_build_state dm_state;
> > +    libxl__domain_create_state *dcs;
> 
> This should be named dm_dcs, I think, to follow the same pattern as
> before.

Sure.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm

[Anthony PERARD]

On Thu, Jan 23, 2020 at 06:17:06PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 23, 2020 at 03:34:25PM +0000, Anthony PERARD wrote:
> > On Tue, Jan 21, 2020 at 10:21:09AM +0000, Roger Pau Monné wrote:
> > > The issue is that this change is passing the guest domain_create_state
> > > to libxl__domain_build in libxl__spawn_stub_dm, and hence the
> > > stubdomain doesn't get created. I have the following patch that fixes
> > > it, but it's kind of dirty.
> > > 
> > > ---8<---
> > > From 688fde95992d07bb1123d324a68006dd08bc6512 Mon Sep 17 00:00:00 2001
> > > From: Roger Pau Monne <roger.pau@citrix.com>
> > > Date: Tue, 21 Jan 2020 10:14:09 +0000
> > > Subject: [PATCH] libxl: fix stubdomain creation after aacc143006429de
> > > MIME-Version: 1.0
> > > Content-Type: text/plain; charset=UTF-8
> > 
> > :-(, this is a lie. The email I've received has a different charset.
> 
> Really? The email headers also contain the same tag, and hence all my
> emails would have a wrong encoding then.

For emails sent by your MUA, I have:
Content-Type: text/plain; charset="iso-8859-1"
There's nothing wrong with that, my MUA uses the same charset. If, in the
patch that I try to apply, I replace the content-type line of the patch
by the one from the email header, git applied the patch just fine and
don't complain.

So, the email encoding is fine.

It is just the copy of an email into another email's body that was an
issue.

> 
> > git
> > complained about it. Maybe next time the patch could be attached, or it
> > could be a proper patch with some note (after ---) (git send-email can
> > do --in-reply-to), or it could be two separated emails with the first
> > one replying to the report and the second the patch (all in the same
> > thread).
> 
> I can certainly send the patch separately as a reply as you say above,
> but I would still need to fix my email client to set the proper
> encoding then.

The email I received was just fine, encoded properly (I think). It is
just trying to apply the patch embedded into the body of the email that
was annoying.

> > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > index 3f08ccad1b..b1ddde77e8 100644
> > > --- a/tools/libxl/libxl_dm.c
> > > +++ b/tools/libxl/libxl_dm.c
> > > @@ -2110,17 +2110,21 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__domain_create_state *dcs)
> > >      xs_transaction_t t;
> > >  
> > >      /* convenience aliases */
> > > -    libxl_domain_config *const dm_config = &sdss->dm_config;
> > >      libxl_domain_config *const guest_config = sdss->dm.guest_config;
> > >      const int guest_domid = sdss->dm.guest_domid;
> > >      libxl__domain_build_state *const d_state = sdss->dm.build_state;
> > > -    libxl__domain_build_state *const stubdom_state = &sdss->dm_state;
> > > +    libxl__domain_build_state *stubdom_state;
> > > +    libxl_domain_config *dm_config;
> > >  
> > >      /* Initialise private part of sdss */
> > > -    libxl__domain_build_state_init(stubdom_state);
> > >      dmss_init(&sdss->dm);
> > >      dmss_init(&sdss->pvqemu);
> > >      libxl__xswait_init(&sdss->xswait);
> > > +    GCNEW(sdss->dcs);
> > > +    stubdom_state = &sdss->dcs->build_state;
> > > +    libxl__domain_build_state_init(stubdom_state);
> > > +    GCNEW(sdss->dcs->guest_config);
> > > +    dm_config = sdss->dcs->guest_config;
> > 
> > I don't think that's enough, we need to initialize the dcs properly.
> > Otherwise, libxl__domain_build() might start using thing that aren't set
> > properly. Maybe we would need a new struct which could be pass to
> > libxl__domain_build*, or that might be more complicated than needed.
> 
> Er likely yes, but creating a complete domain_create_state for the
> stubdom will be very cumbersome I think. Maybe we can copy the one
> from the guest over the stubdom one in order to initialize it?

That's not going to work.

> Not sure that's any better than just using an empty one.

And an "empty one" doesn't work either, the dcs created here contains
more that just the `build_state' and `guest_config', it also contains
for all the _fd field set to something.

The _fd thing is important because Andrew check the value of
`restore_fd' to figure out if a domain is been restored or not.

I don't have better suggestion for now, I'll try to think about it.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm

[Andrew Cooper]

On 23/01/2020 18:15, Anthony PERARD wrote:
> On Thu, Jan 23, 2020 at 06:17:06PM +0100, Roger Pau Monné wrote:
>> On Thu, Jan 23, 2020 at 03:34:25PM +0000, Anthony PERARD wrote:
>>> On Tue, Jan 21, 2020 at 10:21:09AM +0000, Roger Pau Monné wrote:
>>>> The issue is that this change is passing the guest domain_create_state
>>>> to libxl__domain_build in libxl__spawn_stub_dm, and hence the
>>>> stubdomain doesn't get created. I have the following patch that fixes
>>>> it, but it's kind of dirty.
>>>>
>>>> ---8<---
>>>> From 688fde95992d07bb1123d324a68006dd08bc6512 Mon Sep 17 00:00:00 2001
>>>> From: Roger Pau Monne <roger.pau@citrix.com>
>>>> Date: Tue, 21 Jan 2020 10:14:09 +0000
>>>> Subject: [PATCH] libxl: fix stubdomain creation after aacc143006429de
>>>> MIME-Version: 1.0
>>>> Content-Type: text/plain; charset=UTF-8
>>> :-(, this is a lie. The email I've received has a different charset.
>> Really? The email headers also contain the same tag, and hence all my
>> emails would have a wrong encoding then.
> For emails sent by your MUA, I have:
> Content-Type: text/plain; charset="iso-8859-1"
> There's nothing wrong with that, my MUA uses the same charset. If, in the
> patch that I try to apply, I replace the content-type line of the patch
> by the one from the email header, git applied the patch just fine and
> don't complain.
>
> So, the email encoding is fine.
>
> It is just the copy of an email into another email's body that was an
> issue.
>
>>> git
>>> complained about it. Maybe next time the patch could be attached, or it
>>> could be a proper patch with some note (after ---) (git send-email can
>>> do --in-reply-to), or it could be two separated emails with the first
>>> one replying to the report and the second the patch (all in the same
>>> thread).
>> I can certainly send the patch separately as a reply as you say above,
>> but I would still need to fix my email client to set the proper
>> encoding then.
> The email I received was just fine, encoded properly (I think). It is
> just trying to apply the patch embedded into the body of the email that
> was annoying.
>
>>>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>>>> index 3f08ccad1b..b1ddde77e8 100644
>>>> --- a/tools/libxl/libxl_dm.c
>>>> +++ b/tools/libxl/libxl_dm.c
>>>> @@ -2110,17 +2110,21 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__domain_create_state *dcs)
>>>>      xs_transaction_t t;
>>>>  
>>>>      /* convenience aliases */
>>>> -    libxl_domain_config *const dm_config = &sdss->dm_config;
>>>>      libxl_domain_config *const guest_config = sdss->dm.guest_config;
>>>>      const int guest_domid = sdss->dm.guest_domid;
>>>>      libxl__domain_build_state *const d_state = sdss->dm.build_state;
>>>> -    libxl__domain_build_state *const stubdom_state = &sdss->dm_state;
>>>> +    libxl__domain_build_state *stubdom_state;
>>>> +    libxl_domain_config *dm_config;
>>>>  
>>>>      /* Initialise private part of sdss */
>>>> -    libxl__domain_build_state_init(stubdom_state);
>>>>      dmss_init(&sdss->dm);
>>>>      dmss_init(&sdss->pvqemu);
>>>>      libxl__xswait_init(&sdss->xswait);
>>>> +    GCNEW(sdss->dcs);
>>>> +    stubdom_state = &sdss->dcs->build_state;
>>>> +    libxl__domain_build_state_init(stubdom_state);
>>>> +    GCNEW(sdss->dcs->guest_config);
>>>> +    dm_config = sdss->dcs->guest_config;
>>> I don't think that's enough, we need to initialize the dcs properly.
>>> Otherwise, libxl__domain_build() might start using thing that aren't set
>>> properly. Maybe we would need a new struct which could be pass to
>>> libxl__domain_build*, or that might be more complicated than needed.
>> Er likely yes, but creating a complete domain_create_state for the
>> stubdom will be very cumbersome I think. Maybe we can copy the one
>> from the guest over the stubdom one in order to initialize it?
> That's not going to work.
>
>> Not sure that's any better than just using an empty one.
> And an "empty one" doesn't work either, the dcs created here contains
> more that just the `build_state' and `guest_config', it also contains
> for all the _fd field set to something.
>
> The _fd thing is important because Andrew check the value of
> `restore_fd' to figure out if a domain is been restored or not.
>
> I don't have better suggestion for now, I'll try to think about it.

So I did discuss my patch being horrible in the commit message
commentary, but got an ack without any further discussion.  The structs
vs "where useful information is" map is chronically twisted.

An alternative would be to pass down an explicit "clean build" vs
"restore from serialised state" flag, which is the information actually
needed.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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:  aacc143006429de46932aabae17c13846c71fa45
  Bug not present: 2572c7d76e1aee9b11a23c548cee69b15a35401f
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/146664/


  commit aacc143006429de46932aabae17c13846c71fa45
  Author: Andrew Cooper <andrew.cooper3@citrix.com>
  Date:   Thu Jan 2 21:37:36 2020 +0000
  
      tools/libxl: Plumb domain_create_state down into libxl__build_pre()
      
      To fix CPUID handling, libxl__build_pre() is going to have to distinguish
      between a brand new VM vs one which is being migrated-in/resumed.
      
      No functional change.
      
      Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>


For bisection revision-tuple graph see:
   http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.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/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install --summary-out=tmp/146664.bisection-summary --basis-template=146563 --blessings=real,real-bisect xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
 146640 fail [host=debina1] / 146625 [host=rimava1] 146611 [host=elbling1] 146600 [host=albana0] 146584 [host=chardonnay0] 146578 [host=pinot1] 146563 [host=chardonnay1] 146555 [host=italia0] 146543 [host=godello1] 146534 [host=fiano0] 146526 [host=godello0] 146514 [host=fiano1] 146505 [host=huxelrebe0] 146492 [host=huxelrebe1] 146484 [host=albana1] 146119 [host=pinot1] 146094 [host=rimava1] 146050 [host=italia0] 146039 ok.
Failure / basis pass flights: 146640 / 146039
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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 c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 41d8869003e96d8b7250ad1d0246371d6929aca6
Basis pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 8842d01b300919e20bca2e1138c458a8483600f8
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#b98aebd298246df37b472c52a2ee1023256d02e3-c3038e718a19fc596f7b1baba0f83d5146dc7784 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e41\
 0bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef git://xenbits.xen.org/xen.git#8842d01b300919e20bca2e1138c458a8483600f8-41d8869003e96d8b7250ad1d0246371d6929aca6
adhoc-revtuple-generator: tree discontiguous: linux-pvops
Loaded 5002 nodes in revision graph
Searching for test results:
 146006 [host=elbling1]
 146030 [host=godello0]
 146018 [host=albana0]
 146039 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 8842d01b300919e20bca2e1138c458a8483600f8
 146050 [host=italia0]
 146094 [host=rimava1]
 146205 [host=albana1]
 146119 [host=pinot1]
 146206 [host=albana1]
 146176 [host=albana1]
 146234 [host=albana1]
 146215 [host=albana1]
 146217 [host=albana1]
 146219 [host=albana1]
 146220 [host=albana1]
 146222 [host=albana1]
 146226 [host=albana1]
 146227 [host=albana1]
 146229 [host=albana1]
 146230 [host=albana1]
 146231 [host=albana1]
 146232 [host=albana1]
 146221 [host=albana1]
 146257 [host=albana1]
 146286 [host=albana1]
 146340 [host=albana1]
 146408 [host=albana1]
 146319 [host=albana1]
 146350 [host=albana1]
 146365 [host=albana1]
 146379 [host=albana1]
 146393 [host=albana1]
 146419 [host=albana1]
 146471 [host=albana1]
 146445 [host=albana1]
 146492 [host=huxelrebe1]
 146484 [host=albana1]
 146505 [host=huxelrebe0]
 146514 [host=fiano1]
 146526 [host=godello0]
 146534 [host=fiano0]
 146543 [host=godello1]
 146578 [host=pinot1]
 146555 [host=italia0]
 146625 [host=rimava1]
 146563 [host=chardonnay1]
 146600 [host=albana0]
 146611 [host=elbling1]
 146584 [host=chardonnay0]
 146646 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef f268900fbc5b5339f76694e73f14e9261d4b8065
 146641 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 8842d01b300919e20bca2e1138c458a8483600f8
 146659 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 2572c7d76e1aee9b11a23c548cee69b15a35401f
 146640 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 41d8869003e96d8b7250ad1d0246371d6929aca6
 146633 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 41d8869003e96d8b7250ad1d0246371d6929aca6
 146648 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 1eeedaf5a0d9ed6324f3bd5b700bb22eb4355341
 146645 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 41d8869003e96d8b7250ad1d0246371d6929aca6
 146650 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef ad0b3df0f58451c9df26e455148b2d33957bc347
 146653 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 273971c9408bf608605697afd2feb8cdc47c4a35
 146649 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef b6d41060120562e2185f2e3b5e582d415456ec65
 146661 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef aacc143006429de46932aabae17c13846c71fa45
 146657 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef aacc143006429de46932aabae17c13846c71fa45
 146656 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 2572c7d76e1aee9b11a23c548cee69b15a35401f
 146663 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 2572c7d76e1aee9b11a23c548cee69b15a35401f
 146664 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef aacc143006429de46932aabae17c13846c71fa45
 146651 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 41d8869003e96d8b7250ad1d0246371d6929aca6
Searching for interesting versions
 Result found: flight 146039 (pass), for basis pass
 Result found: flight 146633 (fail), for basis failure
 Repro found: flight 146641 (pass), for basis pass
 Repro found: flight 146645 (fail), for basis failure
 0 revisions at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 2572c7d76e1aee9b11a23c548cee69b15a35401f
No revisions left to test, checking graph state.
 Result found: flight 146656 (pass), for last pass
 Result found: flight 146657 (fail), for first failure
 Repro found: flight 146659 (pass), for last pass
 Repro found: flight 146661 (fail), for first failure
 Repro found: flight 146663 (pass), for last pass
 Repro found: flight 146664 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  aacc143006429de46932aabae17c13846c71fa45
  Bug not present: 2572c7d76e1aee9b11a23c548cee69b15a35401f
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/146664/


  commit aacc143006429de46932aabae17c13846c71fa45
  Author: Andrew Cooper <andrew.cooper3@citrix.com>
  Date:   Thu Jan 2 21:37:36 2020 +0000
  
      tools/libxl: Plumb domain_create_state down into libxl__build_pre()
      
      To fix CPUID handling, libxl__build_pre() is going to have to distinguish
      between a brand new VM vs one which is being migrated-in/resumed.
      
      No functional change.
      
      Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

pnmtopng: 250 colors found
Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.{dot,ps,png,html,svg}.
----------------------------------------
146664: tolerable ALL FAIL

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

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail baseline untested


jobs:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        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-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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:  ad011ad08843f60f9ae17b9ae4aa5907674d72af
  Bug not present: 95596f6ab18feb825006ef8f272041f1d94e6bd1
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/143293/


  commit ad011ad08843f60f9ae17b9ae4aa5907674d72af
  Author: Ian Jackson <ian.jackson@eu.citrix.com>
  Date:   Mon Oct 7 17:59:15 2019 +0100
  
      libxl/xl: Overhaul passthrough setting logic
      
      LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
      version of this code) is doing double duty.  We actually need all of
      the following to be specifiable:
        * "default": enable PT iff we have devices to
          pass through specified in the initial config file.
        * "enabled" (and fail if the platform doesn't support it).
        * "disabled" (and reject future PT hotplug).
        * "share_pt"/"sync_pt": enable PT and set a specific PT mode.
      
      Defaulting and error checking should be done in libxl.  So, we make
      several changes here.
      
      We introduce "enabled", and rename "unknown" to "default".
      
      We move all of the error checking and defaulting code from xl into
      libxl.  Now, libxl__domain_config_setdefault has all of the necessary
      information to get this right.  So we can do it all there.  Choosing
      the specific mode is arch-specific.
      
      We can also arrange to have only one place each which calculates
      (i) whether passthrough needs to be enabled because pt devices were
      specified (ii) whether pt_share can be used (for each arch).
      
      xl now only has to parse the enum in the same way as it parses all
      other enums.
      
      This change fixes a regression from earlier 4.13-pre: until recent
      changes, passthrough was only enabled by default if passthrough
      devices were specified.  We restore this behaviour.
      
      Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
      CC: Stefano Stabellini <sstabellini@kernel.org>
      CC: Julien Grall <julien@xen.org>
      CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
      CC: Andrew Cooper <Andrew.Cooper3@citrix.com>
      CC: Paul Durrant <pdurrant@gmail.com>
      CC: Jan Beulich <jbeulich@suse.com>
      Release-acked-by: Juergen Gross <jgross@suse.com>
      Acked-by: Anthony PERARD <anthony.perard@citrix.com>


For bisection revision-tuple graph see:
   http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.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/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install --summary-out=tmp/143293.bisection-summary --basis-template=142750 --blessings=real,real-bisect xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
 143250 fail [host=chardonnay1] / 143133 [host=debina0] 143036 [host=debina1] 143018 [host=albana0] 142973 [host=godello0] 142907 [host=elbling0] 142865 [host=pinot1] 142777 [host=italia0] 142750 [host=huxelrebe1] 142722 [host=rimava1] 142683 [host=albana1] 142642 ok.
Failure / basis pass flights: 143250 / 142642
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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 b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef dfcccc663157c638d9778fa3ada9859f968fb240
Basis pass 42327896f194f256e5a361e0069985bc8d209b42 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef fef8d99fbce1a5e7ddfd22b0f33940b8d6193ec8
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#42327896f194f256e5a361e0069985bc8d209b42-b98aebd298246df37b472c52a2ee1023256d02e3 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e41\
 0bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef git://xenbits.xen.org/xen.git#fef8d99fbce1a5e7ddfd22b0f33940b8d6193ec8-dfcccc663157c638d9778fa3ada9859f968fb240
Loaded 2001 nodes in revision graph
Searching for test results:
 142563 [host=debina0]
 142598 [host=baroque0]
 142642 pass 42327896f194f256e5a361e0069985bc8d209b42 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef fef8d99fbce1a5e7ddfd22b0f33940b8d6193ec8
 142683 [host=albana1]
 142722 [host=rimava1]
 142777 [host=italia0]
 142750 [host=huxelrebe1]
 142865 [host=pinot1]
 142907 [host=elbling0]
 142973 [host=godello0]
 143018 [host=albana0]
 143036 [host=debina1]
 143133 [host=debina0]
 143244 pass 797d4cf8fc21b3b8366d2543d8f3c46288304b1a c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 00fc9004be169a065c10a5fb699e353e430190c2
 143247 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef dfcccc663157c638d9778fa3ada9859f968fb240
 143250 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef dfcccc663157c638d9778fa3ada9859f968fb240
 143172 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 64b5d83460af4654b88c6598ede7e74dd37dce2e
 143239 pass 38ce8792c0f2a29aad60197d5a10e963759ddc1f c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 00fc9004be169a065c10a5fb699e353e430190c2
 143262 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef af5c475deed3b95a6a69cd4c0ef68132b487c079
 143237 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 64b5d83460af4654b88c6598ede7e74dd37dce2e
 143233 pass 42327896f194f256e5a361e0069985bc8d209b42 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef fef8d99fbce1a5e7ddfd22b0f33940b8d6193ec8
 143205 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef dfcccc663157c638d9778fa3ada9859f968fb240
 143253 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef a7ecdf8139e3646c0eb9c9bd9ed0fe3b344e6fed
 143257 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 3f21bd497747fbfe6e548a3c50b55dfe21a1eefb
 143266 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef ad011ad08843f60f9ae17b9ae4aa5907674d72af
 143268 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 5f135a65d2803f3636f52895cc811ec66576a8db
 143274 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 95596f6ab18feb825006ef8f272041f1d94e6bd1
 143278 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef ad011ad08843f60f9ae17b9ae4aa5907674d72af
 143280 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 95596f6ab18feb825006ef8f272041f1d94e6bd1
 143283 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef ad011ad08843f60f9ae17b9ae4aa5907674d72af
 143289 pass b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 95596f6ab18feb825006ef8f272041f1d94e6bd1
 143293 fail b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef ad011ad08843f60f9ae17b9ae4aa5907674d72af
Searching for interesting versions
 Result found: flight 142642 (pass), for basis pass
 Result found: flight 143205 (fail), for basis failure
 Repro found: flight 143233 (pass), for basis pass
 Repro found: flight 143247 (fail), for basis failure
 0 revisions at b98aebd298246df37b472c52a2ee1023256d02e3 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 95596f6ab18feb825006ef8f272041f1d94e6bd1
No revisions left to test, checking graph state.
 Result found: flight 143274 (pass), for last pass
 Result found: flight 143278 (fail), for first failure
 Repro found: flight 143280 (pass), for last pass
 Repro found: flight 143283 (fail), for first failure
 Repro found: flight 143289 (pass), for last pass
 Repro found: flight 143293 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  ad011ad08843f60f9ae17b9ae4aa5907674d72af
  Bug not present: 95596f6ab18feb825006ef8f272041f1d94e6bd1
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/143293/


  commit ad011ad08843f60f9ae17b9ae4aa5907674d72af
  Author: Ian Jackson <ian.jackson@eu.citrix.com>
  Date:   Mon Oct 7 17:59:15 2019 +0100
  
      libxl/xl: Overhaul passthrough setting logic
      
      LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
      version of this code) is doing double duty.  We actually need all of
      the following to be specifiable:
        * "default": enable PT iff we have devices to
          pass through specified in the initial config file.
        * "enabled" (and fail if the platform doesn't support it).
        * "disabled" (and reject future PT hotplug).
        * "share_pt"/"sync_pt": enable PT and set a specific PT mode.
      
      Defaulting and error checking should be done in libxl.  So, we make
      several changes here.
      
      We introduce "enabled", and rename "unknown" to "default".
      
      We move all of the error checking and defaulting code from xl into
      libxl.  Now, libxl__domain_config_setdefault has all of the necessary
      information to get this right.  So we can do it all there.  Choosing
      the specific mode is arch-specific.
      
      We can also arrange to have only one place each which calculates
      (i) whether passthrough needs to be enabled because pt devices were
      specified (ii) whether pt_share can be used (for each arch).
      
      xl now only has to parse the enum in the same way as it parses all
      other enums.
      
      This change fixes a regression from earlier 4.13-pre: until recent
      changes, passthrough was only enabled by default if passthrough
      devices were specified.  We restore this behaviour.
      
      Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
      CC: Stefano Stabellini <sstabellini@kernel.org>
      CC: Julien Grall <julien@xen.org>
      CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
      CC: Andrew Cooper <Andrew.Cooper3@citrix.com>
      CC: Paul Durrant <pdurrant@gmail.com>
      CC: Jan Beulich <jbeulich@suse.com>
      Release-acked-by: Juergen Gross <jgross@suse.com>
      Acked-by: Anthony PERARD <anthony.perard@citrix.com>

pnmtopng: 218 colors found
Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.{dot,ps,png,html,svg}.
----------------------------------------
143293: tolerable ALL FAIL

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

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail baseline untested


jobs:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        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-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel