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

2023-12-09 Thread 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:  bc4fe94a69d4dab103c37045d97e589ef75f8647
  Bug not present: e6e8c5831a64420a56f83e87919ed157ab810fab
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/184065/


  commit bc4fe94a69d4dab103c37045d97e589ef75f8647
  Author: Juergen Gross 
  Date:   Thu Dec 7 07:25:51 2023 +0100
  
  tools/libs/evtchn: replace assert()s in stubdom with proper locking
  
  In tools/libs/evtchn/minios.c there are assert()s for the current
  thread being the main thread when binding an event channel.
  
  As Mini-OS is supporting multiple threads, there is no real reason
  why the binding shouldn't be allowed to happen in any other thread.
  
  Drop the assert()s and replace them with proper locking of the
  port_list.
  
  Signed-off-by: Juergen Gross 
  Reviewed-by: Jason Andryuk 


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/184065.bisection-summary --basis-template=184031 
--blessings=real,real-bisect,real-retry xen-unstable 
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
 184053 fail [host=sabro0] / 184031 [host=albana1] 184020 [host=elbling0] 
184005 [host=italia0] 183996 [host=sabro1] 183990 [host=elbling1] 183983 
[host=godello0] 183978 [host=nobling1] 183974 [host=fiano0] 183971 
[host=italia1] 183965 [host=rimava1] 183959 [host=nobling0] 183952 
[host=godello1] 183938 [host=debina0] 183922 [host=himrod0] 183877 
[host=fiano1] 183860 [host=albana0] 183855 [host=nobling0] 183852 
[host=debina1] 183847 [host=italia0] 183839 [host=albana1] 183831 ok.
Failure / basis pass flights: 184053 / 183831
(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 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
0df9387c8983e1b1e72d8c574356f572342c03e6 
bc4fe94a69d4dab103c37045d97e589ef75f8647
Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
0df9387c8983e1b1e72d8c574356f572342c03e6 
c22fe7213c9b1f99cbc64c33e391afa223f9cd08
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c7437ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764
 git://xenbits.xen.org/qemu-xen.git#0df9387c8983e1b1e72d8c574356f57\
 2342c03e6-0df9387c8983e1b1e72d8c574356f572342c03e6 
git://xenbits.xen.org/xen.git#c22fe7213c9b1f99cbc64c33e391afa223f9cd08-bc4fe94a69d4dab103c37045d97e589ef75f8647
Loaded 5001 nodes in revision graph
Searching for test results:
 183831 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
0df9387c8983e1b1e72d8c574356f572342c03e6 
c22fe7213c9b1f99cbc64c33e391afa223f9cd08
 183839 [host=albana1]
 183847 [host=italia0]
 183852 [host=debina1]
 183855 [host=nobling0]
 183860 [host=albana0]
 183877 [host=fiano1]
 183922 [host=himrod0]
 183938 [host=debina0]
 183952 [host=godello1]
 183959 [host=nobling0]
 183965 [host=rimava1]
 183971 [host=italia1]
 183990 [host=elbling1]
 183974 [host=fiano0]
 183978 [host=nobling1]
 183983 [host=godello0]
 183996 [host=sabro1]
 184005 [host=italia0]
 184020 [host=elbling0]
 184031 [host=albana1]
 184036 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
0df9387c8983e1b1e72d8c574356f572342c03e6

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

2022-11-19 Thread osstest service owner 
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
testid guest-saverestore

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:  7c3bbd940dd8aeb1649734e5055798cc6f3fea4e
  Bug not present: bd87315a603bf25e869e6293f7db7b1024d67999
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/174840/


  commit 7c3bbd940dd8aeb1649734e5055798cc6f3fea4e
  Author: Andrew Cooper 
  Date:   Tue Oct 25 15:27:05 2022 +0100
  
  xen/arm, libxl: Revert XEN_DOMCTL_shadow_op; use p2m mempool hypercalls
  
  This reverts most of commit cf2a68d2ffbc3ce95e01449d46180bddb10d24a0, and 
bits
  of cbea5a1149ca7fd4b7cdbfa3ec2e4f109b601ff7.
  
  First of all, with ARM borrowing x86's implementation, the logic to set 
the
  pool size should have been common, not duplicated.  Introduce
  libxl__domain_set_paging_mempool_size() as a shared implementation, and 
use it
  from the ARM and x86 paths.  It is left as an exercise to the reader to 
judge
  how libxl/xl can reasonably function without the ability to query the pool
  size...
  
  Remove ARM's p2m_domctl() infrastructure now the functioanlity has been
  replaced with a working and unit tested interface.
  
  This is part of XSA-409 / CVE-2022-33747.
  
  Signed-off-by: Andrew Cooper 
  Reviewed-by: Stefano Stabellini 
  Reviewed-by: Anthony PERARD 
  Release-acked-by: Henry Wang 


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.guest-saverestore.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.guest-saverestore
 --summary-out=tmp/174840.bisection-summary --basis-template=174797 
--blessings=real,real-bisect,real-retry xen-unstable 
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm guest-saverestore
Searching for failure / basis pass:
 174826 fail [host=nocera1] / 174797 [host=fiano0] 174791 [host=debina1] 174773 
[host=pinot1] 174769 [host=albana1] 174762 [host=sabro1] 174753 [host=godello1] 
174747 [host=huxelrebe0] 174742 [host=elbling0] 174733 [host=himrod0] 174724 
[host=pinot0] 174701 [host=italia1] 174682 [host=nobling1] 174670 
[host=nocera0] 174663 [host=nobling0] 174652 [host=godello0] 174641 
[host=italia0] 174636 [host=elbling1] 174629 [host=chardonnay1] 174607 
[host=chardonnay0] 174597 [host=albana0] 174586 [host=debi\
 na0] 174574 ok.
Failure / basis pass flights: 174826 / 174574
(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 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
b746458e1ce1bec85e58b458386f8b7a0bedfaa6 
db8fa01c61db0317a9ee947925226234c65d48e8
Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
b746458e1ce1bec85e58b458386f8b7a0bedfaa6 
2dd823ca7237e7fb90c890642d6a3b357a26fcff
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c7437ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764
 git://xenbits.xen.org/qemu-xen.git#b746458e1ce1bec85e58b458386f8b7\
 a0bedfaa6-b746458e1ce1bec85e58b458386f8b7a0bedfaa6 
git://xenbits.xen.org/xen.git#2dd823ca7237e7fb90c890642d6a3b357a26fcff-db8fa01c61db0317a9ee947925226234c65d48e8
Loaded 5001 nodes in revision graph
Searching for test results:
 174574 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
b746458e1ce1bec85e58b458386f8b7a0bedfaa6 
2dd823ca7237e7fb90c890642d6a3b357a26fcff
 174586 [host=debina0]
 174597 [host=albana0]
 174607 [host=chardonnay0]
 174629 [host=chardonnay1]
 174636 [host=elbling1]
 174641 [host=italia0]
 174652 [host=godello0]
 174663

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

2020-11-10 Thread 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:  e19bcb626f50a652fb1854a8b2f2c9c371687a11
  Bug not present: c3453a23f7905d24f2404787543e26ec7d02301c
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/156664/


  commit e19bcb626f50a652fb1854a8b2f2c9c371687a11
  Author: Juergen Gross 
  Date:   Fri Nov 6 10:48:07 2020 +0100
  
  xen/rwlock: add check_lock() handling to rwlocks
  
  Checking whether a lock is consistently used regarding interrupts on
  or off is beneficial for rwlocks, too.
  
  So add check_lock() calls to rwlock functions. For this purpose make
  check_lock() globally accessible.
  
  Signed-off-by: Juergen Gross 
  Reviewed-by: Julien Grall 
  Reviewed-by: Jan Beulich 


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/156664.bisection-summary --basis-template=156443 
--blessings=real,real-bisect,real-retry xen-unstable 
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
 156608 fail [host=godello0] / 156443 [host=albana0] 156401 [host=huxelrebe1] 
156389 [host=godello1] 156373 [host=albana1] 156354 [host=fiano1] 156339 ok.
Failure / basis pass flights: 156608 / 156339
(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 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
0a5e0ce0fb7e5a3b5dfdc936058d2c0e04e5e258
Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
677cbe1324c29294bb1d1b8454b3f214725e40fd 
7056f2f89f03f2f804ac7e776c7b2b000cd716cd
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c7437ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764
 git://xenbits.xen.org/qemu-xen.git#677cbe1324c29294bb1d1b8454b3f21\
 4725e40fd-7ea428895af2840d85c524f0bd11a38aac308308 
git://xenbits.xen.org/xen.git#7056f2f89f03f2f804ac7e776c7b2b000cd716cd-0a5e0ce0fb7e5a3b5dfdc936058d2c0e04e5e258
Loaded 10007 nodes in revision graph
Searching for test results:
 156331 [host=elbling0]
 156339 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
677cbe1324c29294bb1d1b8454b3f214725e40fd 
7056f2f89f03f2f804ac7e776c7b2b000cd716cd
 156354 [host=fiano1]
 156373 [host=albana1]
 156389 [host=godello1]
 156401 [host=huxelrebe1]
 156443 [host=albana0]
 156524 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
677cbe1324c29294bb1d1b8454b3f214725e40fd 
2a5f9f6a6932214fda76b9b3c03e024772882d34
 156538 fail irrelevant
 156556 fail irrelevant
 156577 fail irrelevant
 156588 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
0a5e0ce0fb7e5a3b5dfdc936058d2c0e04e5e258
 156626 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
677cbe1324c29294bb1d1b8454b3f214725e40fd 
7056f2f89f03f2f804ac7e776c7b2b000cd716cd
 156627 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
0a5e0ce0fb7e5a3b5dfdc936058d2c0e04e5e258
 156629 pass

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

2020-02-02 Thread 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 
  Date:   Thu Jan 2 21:37:36 2020 +
  
  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 
  Acked-by: Ian Jackson 


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

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

2020-01-23 Thread 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 +, Anthony PERARD wrote:
>>> On Tue, Jan 21, 2020 at 10:21:09AM +, 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 
 Date: Tue, 21 Jan 2020 10:14:09 +
 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 = >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 = >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(>dm);
  dmss_init(>pvqemu);
  libxl__xswait_init(>xswait);
 +GCNEW(sdss->dcs);
 +stubdom_state = >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

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

2020-01-23 Thread 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 +, Anthony PERARD wrote:
> > On Tue, Jan 21, 2020 at 10:21:09AM +, 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 
> > > Date: Tue, 21 Jan 2020 10:14:09 +
> > > 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 = >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 = >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(>dm);
> > >  dmss_init(>pvqemu);
> > >  libxl__xswait_init(>xswait);
> > > +GCNEW(sdss->dcs);
> > > +stubdom_state = >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

2020-01-23 Thread Roger Pau Monné 
On Thu, Jan 23, 2020 at 03:34:25PM +, Anthony PERARD wrote:
> On Tue, Jan 21, 2020 at 10:21:09AM +, 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 
> > Date: Tue, 21 Jan 2020 10:14:09 +
> > 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é 
> > ---
> >  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 = >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 = >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(>dm);
> >  dmss_init(>pvqemu);
> >  libxl__xswait_init(>xswait);
> > +GCNEW(sdss->dcs);
> > +stubdom_state = >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(,>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

2020-01-23 Thread Anthony PERARD 
On Tue, Jan 21, 2020 at 10:21:09AM +, 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 
> Date: Tue, 21 Jan 2020 10:14:09 +
> 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é 
> ---
>  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 = >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 = >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(>dm);
>  dmss_init(>pvqemu);
>  libxl__xswait_init(>xswait);
> +GCNEW(sdss->dcs);
> +stubdom_state = >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(,>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

2020-01-21 Thread Roger Pau Monné 
On Sun, Jan 19, 2020 at 03:17:13AM +, 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 
>   Date:   Thu Jan 2 21:37:36 2020 +
>   
>   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 
>   Acked-by: Ian Jackson 

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 
Date: Tue, 21 Jan 2020 10:14:09 +
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é 
---
 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 = >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 = >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(>dm);
 dmss_init(>pvqemu);
 libxl__xswait_init(>xswait);
+GCNEW(sdss->dcs);
+stubdom_state = >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 = >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 = >dm_state;
+libxl__domain_build_state *const stubdom_state = >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 = >dm_config;
-sdss->pvqemu.build_state = >dm_state;
+sdss->pvqemu.guest_config = sdss->dcs->guest_config;
+sdss->pvqemu.build_state = >dcs->build_state;
 sdss->pvqemu.callback = spawn_stubdom_pvqemu_cb;
 
 if (!need_qemu) {
@@ -2464,7 +2468,7 @@ static void

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

2020-01-18 Thread 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 
  Date:   Thu Jan 2 21:37:36 2020 +
  
  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 
  Acked-by: Ian Jackson 


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

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

2019-10-28 Thread 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 
  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 
  CC: Stefano Stabellini 
  CC: Julien Grall 
  CC: Volodymyr Babchuk 
  CC: Andrew Cooper 
  CC: Paul Durrant 
  CC: Jan Beulich 
  Release-acked-by: Juergen Gross 
  Acked-by: Anthony PERARD 


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

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

2018-04-01 Thread 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:  55e0590e4bed56db0ea628826409572c94c54ebf
  Bug not present: ca45928e46e300c5de70a779c2a84d1f0e77b8d2
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/121536/


  commit 55e0590e4bed56db0ea628826409572c94c54ebf
  Author: Wei Liu 
  Date:   Tue Mar 27 17:20:50 2018 +0100
  
  Config.mk: update mini-os commit
  
  Signed-off-by: Wei Liu 


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/121536.bisection-summary --basis-template=121272 
--blessings=real,real-bisect xen-unstable 
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
 121342 fail [host=elbling0] / 121307 [host=godello1] 121272 [host=baroque1] 
121059 [host=italia0] 120988 [host=elbling1] 120943 [host=fiano0] 120859 
[host=huxelrebe0] 120767 [host=chardonnay0] 120626 ok.
Failure / basis pass flights: 121342 / 120626
(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 24f70aa804cd7f8fee4353cf4990997d1c8375ae 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5c3fdee026a204a59cb392e43a313ab558de9682 
e5fe34fd23816601de17b0a428909c95acf01c93
Basis pass 6a83eb2354543e3263b880eb822c4b0993a2236b 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5c3fdee026a204a59cb392e43a313ab558de9682 
966f154c58bacf07690135d7da3f1d5281d84ab0
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#6a83eb2354543e3263b880eb822c4b0993a2236b-24f70aa804cd7f8fee4353cf4990997d1c8375ae
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
 
git://xenbits.xen.org/qemu-xen.git#5c3fdee026a204a59cb392e43a313ab558de9682-5c3fdee026a204a59cb392e43a313ab558de9682
 
git://xenbits.xen.org/xen.git#966f154c58bacf07690135d7da3f1d5281d84ab0-e5fe34fd23816601de17b0a428909c95acf01c93
Loaded 2001 nodes in revision graph
Searching for test results:
 120626 pass 6a83eb2354543e3263b880eb822c4b0993a2236b 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5c3fdee026a204a59cb392e43a313ab558de9682 
966f154c58bacf07690135d7da3f1d5281d84ab0
 120767 [host=chardonnay0]
 120859 [host=huxelrebe0]
 120943 [host=fiano0]
 120988 [host=elbling1]
 121059 [host=italia0]
 121272 [host=baroque1]
 121307 [host=godello1]
 121341 pass 6a83eb2354543e3263b880eb822c4b0993a2236b 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5c3fdee026a204a59cb392e43a313ab558de9682 
966f154c58bacf07690135d7da3f1d5281d84ab0
 121322 fail 24f70aa804cd7f8fee4353cf4990997d1c8375ae 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5c3fdee026a204a59cb392e43a313ab558de9682 
73a10cb91a4e5c6f7049a78a12dcdea3460f0bd1
 121376 fail 24f70aa804cd7f8fee4353cf4990997d1c8375ae 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5c3fdee026a204a59cb392e43a313ab558de9682 
73a10cb91a4e5c6f7049a78a12dcdea3460f0bd1
 121378 pass c86742fc38993fd42672c55cec0ae537279e3fbb 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5c3fdee026a204a59cb392e43a313ab558de9682 
8df3821c08d024684a6c83659d8d794b565067f9
 121342 fail 24f70aa804cd7f8fee4353cf4990997d1c8375ae 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5c3fdee026a204a59cb392e43a313ab558de9682 
e5fe34fd23816601de17b0a428909c95acf01c93
 121386 pass f5df9a59c68ea8272960cb88d31434ccb69b3510 
c530a75c1e6a472b0eb9558310b518f0dfcd8860