* [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
@ 2020-02-02 8:41 osstest service owner
0 siblings, 0 replies; 8+ messages in thread
From: osstest service owner @ 2020-02-02 8:41 UTC (permalink / raw)
To: xen-devel, osstest-admin
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
^ permalink raw reply [flat|nested] 8+ messages in thread* [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
@ 2020-01-19 3:17 osstest service owner
2020-01-21 10:21 ` Roger Pau Monné
0 siblings, 1 reply; 8+ messages in thread
From: osstest service owner @ 2020-01-19 3:17 UTC (permalink / raw)
To: xen-devel, osstest-admin
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
2020-01-19 3:17 osstest service owner
@ 2020-01-21 10:21 ` Roger Pau Monné
2020-01-23 15:34 ` Anthony PERARD
0 siblings, 1 reply; 8+ messages in thread
From: Roger Pau Monné @ 2020-01-21 10:21 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Anthony PERARD, xen-devel, Ian Jackson, Wei Liu
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
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
2020-01-21 10:21 ` Roger Pau Monné
@ 2020-01-23 15:34 ` Anthony PERARD
2020-01-23 17:17 ` Roger Pau Monné
0 siblings, 1 reply; 8+ messages in thread
From: Anthony PERARD @ 2020-01-23 15:34 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: Andrew Cooper, Ian Jackson, Wei Liu, xen-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
2020-01-23 15:34 ` Anthony PERARD
@ 2020-01-23 17:17 ` Roger Pau Monné
2020-01-23 18:15 ` Anthony PERARD
0 siblings, 1 reply; 8+ messages in thread
From: Roger Pau Monné @ 2020-01-23 17:17 UTC (permalink / raw)
To: Anthony PERARD; +Cc: Andrew Cooper, Ian Jackson, Wei Liu, xen-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
2020-01-23 17:17 ` Roger Pau Monné
@ 2020-01-23 18:15 ` Anthony PERARD
2020-01-23 18:32 ` Andrew Cooper
0 siblings, 1 reply; 8+ messages in thread
From: Anthony PERARD @ 2020-01-23 18:15 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: Andrew Cooper, Ian Jackson, Wei Liu, xen-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
2020-01-23 18:15 ` Anthony PERARD
@ 2020-01-23 18:32 ` Andrew Cooper
0 siblings, 0 replies; 8+ messages in thread
From: Andrew Cooper @ 2020-01-23 18:32 UTC (permalink / raw)
To: Anthony PERARD, Roger Pau Monné; +Cc: xen-devel, Ian Jackson, Wei Liu
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
@ 2019-10-28 19:35 osstest service owner
0 siblings, 0 replies; 8+ messages in thread
From: osstest service owner @ 2019-10-28 19:35 UTC (permalink / raw)
To: xen-devel, osstest-admin
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-02-02 8:42 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-02 8:41 [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm osstest service owner
-- strict thread matches above, loose matches on Subject: below --
2020-01-19 3:17 osstest service owner
2020-01-21 10:21 ` Roger Pau Monné
2020-01-23 15:34 ` Anthony PERARD
2020-01-23 17:17 ` Roger Pau Monné
2020-01-23 18:15 ` Anthony PERARD
2020-01-23 18:32 ` Andrew Cooper
2019-10-28 19:35 osstest service owner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).