* [Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm
@ 2019-06-26 4:16 osstest service owner
0 siblings, 0 replies; 7+ messages in thread
From: osstest service owner @ 2019-06-26 4:16 UTC (permalink / raw)
To: xen-devel, osstest-admin
[-- Attachment #1: Type: text/plain, Size: 7671 bytes --]
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
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: b41666f2c17f01c437c870389ab713ee62ae3526
Bug not present: 85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/138530/
commit b41666f2c17f01c437c870389ab713ee62ae3526
Author: Roger Pau Monné <roger.pau@citrix.com>
Date: Tue Jun 25 15:39:44 2019 +0200
config: don't hardcode toolchain binaries
Currently the names of the build toolchain binaries are hardcoded in
StdGNU.mk, and the values from the environment are ignored.
Switch StdGNU.mk to use '?=' instead of '=', so that values from the
environment are used if present, else default to the values provided
by the config file.
This change fixes the gitlab CI loop, that was relying on passing
custom values in the environment variables for the compiler and the
linker.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-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-smoke/build-arm64-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build --summary-out=tmp/138530.bisection-summary --basis-template=138424 --blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build
Searching for failure / basis pass:
138519 fail [host=laxton1] / 138424 [host=laxton0] 138355 [host=laxton0] 138347 [host=rochester1] 138342 ok.
Failure / basis pass flights: 138519 / 138342
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 9cca02d8ffc23e9688a971d858e4ffdff5389b11 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Basis pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 11911563610786615c2b3a01cdcaaf09a6f9e38d
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-9cca02d8ffc23e9688a971d858e4ffdff5389b11 git://xenbits.xen.org/xen.git#11911563610786615c2b3a01cdcaaf09a6f9e38d-1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Loaded 1001 nodes in revision graph
Searching for test results:
138262 [host=rochester1]
138257 [host=rochester1]
138242 [host=rochester1]
138268 [host=rochester0]
138271 [host=rochester1]
138277 [host=rochester0]
138294 [host=rochester0]
138295 [host=rochester0]
138302 [host=rochester0]
138355 [host=laxton0]
138328 [host=rochester0]
138317 [host=laxton0]
138347 [host=rochester1]
138342 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 11911563610786615c2b3a01cdcaaf09a6f9e38d
138424 [host=laxton0]
138493 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
138482 [host=rochester0]
138489 [host=rochester1]
138485 [host=rochester0]
138497 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
138501 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
138505 [host=rochester1]
138510 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
138517 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
138519 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
138522 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 11911563610786615c2b3a01cdcaaf09a6f9e38d
138523 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
138524 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 560cf418c8455cd8d79ad353f6f9193a2e2554e4
138525 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
138526 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 b41666f2c17f01c437c870389ab713ee62ae3526
138527 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
138528 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 b41666f2c17f01c437c870389ab713ee62ae3526
138529 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
138530 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 b41666f2c17f01c437c870389ab713ee62ae3526
Searching for interesting versions
Result found: flight 138342 (pass), for basis pass
Result found: flight 138493 (fail), for basis failure
Repro found: flight 138522 (pass), for basis pass
Repro found: flight 138523 (fail), for basis failure
0 revisions at 9cca02d8ffc23e9688a971d858e4ffdff5389b11 85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
No revisions left to test, checking graph state.
Result found: flight 138525 (pass), for last pass
Result found: flight 138526 (fail), for first failure
Repro found: flight 138527 (pass), for last pass
Repro found: flight 138528 (fail), for first failure
Repro found: flight 138529 (pass), for last pass
Repro found: flight 138530 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: b41666f2c17f01c437c870389ab713ee62ae3526
Bug not present: 85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/138530/
commit b41666f2c17f01c437c870389ab713ee62ae3526
Author: Roger Pau Monné <roger.pau@citrix.com>
Date: Tue Jun 25 15:39:44 2019 +0200
config: don't hardcode toolchain binaries
Currently the names of the build toolchain binaries are hardcoded in
StdGNU.mk, and the values from the environment are ignored.
Switch StdGNU.mk to use '?=' instead of '=', so that values from the
environment are used if present, else default to the values provided
by the config file.
This change fixes the gitlab CI loop, that was relying on passing
custom values in the environment variables for the compiler and the
linker.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-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-smoke/build-arm64-xsm.xen-build.{dot,ps,png,html,svg}.
----------------------------------------
138530: tolerable ALL FAIL
flight 138530 xen-unstable-smoke real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/138530/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
build-arm64-xsm 6 xen-build fail baseline untested
jobs:
build-arm64-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
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 7+ messages in thread* [Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm
@ 2020-02-12 16:13 osstest service owner
0 siblings, 0 replies; 7+ messages in thread
From: osstest service owner @ 2020-02-12 16:13 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
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: 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
Bug not present: dacb80f9757c011161cec6609f39837c9ea8caa8
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/146964/
commit 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Feb 5 15:25:21 2020 +0000
tools/libxl: Combine legacy CPUID handling logic
While we are in the process of overhauling boot time CPUID/MSR handling, the
existing logic is going to have to remain in roughly this form for backwards
compatibility.
Fold libxl__cpuid_apply_policy() and libxl__cpuid_set() together into a single
libxl__cpuid_legacy() to reduce the complexity for callers.
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-smoke/build-arm64-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build --summary-out=tmp/146964.bisection-summary --basis-template=146882 --blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build
Searching for failure / basis pass:
146950 fail [host=laxton0] / 146882 [host=rochester0] 146871 [host=rochester0] 146838 [host=laxton1] 146835 [host=rochester1] 146832 [host=rochester0] 146767 ok.
Failure / basis pass flights: 146950 / 146767
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 933ebad2470a169504799a1d95b8e410bd9847ef af09b7d79cb8ae7498882e61efec75486eb69544
Basis pass 933ebad2470a169504799a1d95b8e410bd9847ef 72dbcf0c065037dddb591a072c4f8f16fe888ea8
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e410bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef git://xenbits.xen.org/xen.git#72dbcf0c065037dddb591a072c4f8f16fe888ea8-af09b7d79cb8ae7498882e61efec75486eb69544
Loaded 5001 nodes in revision graph
Searching for test results:
146767 pass 933ebad2470a169504799a1d95b8e410bd9847ef 72dbcf0c065037dddb591a072c4f8f16fe888ea8
146832 [host=rochester0]
146835 [host=rochester1]
146838 [host=laxton1]
146871 [host=rochester0]
146882 [host=rochester0]
146893 [host=rochester1]
146899 [host=rochester0]
146909 [host=rochester1]
146964 fail 933ebad2470a169504799a1d95b8e410bd9847ef 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
146947 [host=laxton1]
146918 [host=laxton1]
146935 fail 933ebad2470a169504799a1d95b8e410bd9847ef af09b7d79cb8ae7498882e61efec75486eb69544
146948 [host=laxton1]
146925 [host=laxton1]
146949 pass 933ebad2470a169504799a1d95b8e410bd9847ef 72dbcf0c065037dddb591a072c4f8f16fe888ea8
146951 fail 933ebad2470a169504799a1d95b8e410bd9847ef af09b7d79cb8ae7498882e61efec75486eb69544
146952 pass 933ebad2470a169504799a1d95b8e410bd9847ef 3dd724dff085e13ad520f8e35aea717db2ff07d0
146928 [host=laxton1]
146953 pass 933ebad2470a169504799a1d95b8e410bd9847ef 4e9929f5bde62e19653a4c7f5792648f56ef35ab
146954 fail 933ebad2470a169504799a1d95b8e410bd9847ef 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
146955 pass 933ebad2470a169504799a1d95b8e410bd9847ef 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c
146939 [host=laxton1]
146940 [host=laxton1]
146956 pass 933ebad2470a169504799a1d95b8e410bd9847ef dacb80f9757c011161cec6609f39837c9ea8caa8
146941 [host=laxton1]
146942 [host=laxton1]
146957 fail 933ebad2470a169504799a1d95b8e410bd9847ef 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
146958 pass 933ebad2470a169504799a1d95b8e410bd9847ef dacb80f9757c011161cec6609f39837c9ea8caa8
146950 fail 933ebad2470a169504799a1d95b8e410bd9847ef af09b7d79cb8ae7498882e61efec75486eb69544
146959 fail 933ebad2470a169504799a1d95b8e410bd9847ef 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
146961 pass 933ebad2470a169504799a1d95b8e410bd9847ef dacb80f9757c011161cec6609f39837c9ea8caa8
Searching for interesting versions
Result found: flight 146767 (pass), for basis pass
Result found: flight 146935 (fail), for basis failure
Repro found: flight 146949 (pass), for basis pass
Repro found: flight 146950 (fail), for basis failure
0 revisions at 933ebad2470a169504799a1d95b8e410bd9847ef dacb80f9757c011161cec6609f39837c9ea8caa8
No revisions left to test, checking graph state.
Result found: flight 146956 (pass), for last pass
Result found: flight 146957 (fail), for first failure
Repro found: flight 146958 (pass), for last pass
Repro found: flight 146959 (fail), for first failure
Repro found: flight 146961 (pass), for last pass
Repro found: flight 146964 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
Bug not present: dacb80f9757c011161cec6609f39837c9ea8caa8
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/146964/
commit 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Feb 5 15:25:21 2020 +0000
tools/libxl: Combine legacy CPUID handling logic
While we are in the process of overhauling boot time CPUID/MSR handling, the
existing logic is going to have to remain in roughly this form for backwards
compatibility.
Fold libxl__cpuid_apply_policy() and libxl__cpuid_set() together into a single
libxl__cpuid_legacy() to reduce the complexity for callers.
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-smoke/build-arm64-xsm.xen-build.{dot,ps,png,html,svg}.
----------------------------------------
146964: tolerable ALL FAIL
flight 146964 xen-unstable-smoke real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/146964/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
build-arm64-xsm 6 xen-build fail baseline untested
jobs:
build-arm64-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] 7+ messages in thread* [Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm
@ 2020-01-24 0:21 osstest service owner
0 siblings, 0 replies; 7+ messages in thread
From: osstest service owner @ 2020-01-24 0:21 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
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: ea22bcd030da771be18821bf4a898ed7a314eb83
Bug not present: 5160dbd512523d865f7271af23636aa3f3536186
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/146449/
commit ea22bcd030da771be18821bf4a898ed7a314eb83
Author: Alexandru Stefan ISAILA <aisaila@bitdefender.com>
Date: Fri Jan 17 13:31:30 2020 +0000
x86/altp2m: Add hypercall to set a range of sve bits
By default the sve bits are not set.
This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
to set a range of sve bits.
The core function, p2m_set_suppress_ve_multi(), does not break in case
of a error and it is doing a best effort for setting the bits in the
given range. A check for continuation is made in order to have
preemption on large ranges.
The gfn of the first error is stored in
xen_hvm_altp2m_suppress_ve_multi.first_error_gfn and the error code is
stored in xen_hvm_altp2m_suppress_ve_multi.first_error.
If no error occurred the values will be 0.
Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Petre Pircalabu <ppircalabu@bitdefender.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build --summary-out=tmp/146449.bisection-summary --basis-template=146401 --blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build
Searching for failure / basis pass:
146438 fail [host=rochester0] / 146401 [host=rochester1] 146396 [host=laxton0] 146390 [host=laxton1] 146367 [host=laxton1] 146362 [host=laxton1] 146353 [host=laxton1] 146330 [host=rochester1] 146321 [host=rochester1] 146218 ok.
Failure / basis pass flights: 146438 / 146218
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 933ebad2470a169504799a1d95b8e410bd9847ef 2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
Basis pass 933ebad2470a169504799a1d95b8e410bd9847ef 1eeedaf5a0d9ed6324f3bd5b700bb22eb4355341
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e410bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef git://xenbits.xen.org/xen.git#1eeedaf5a0d9ed6324f3bd5b700bb22eb4355341-2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
Loaded 5001 nodes in revision graph
Searching for test results:
146218 pass 933ebad2470a169504799a1d95b8e410bd9847ef 1eeedaf5a0d9ed6324f3bd5b700bb22eb4355341
146321 [host=rochester1]
146330 [host=rochester1]
146367 [host=laxton1]
146353 [host=laxton1]
146362 [host=laxton1]
146390 [host=laxton1]
146396 [host=laxton0]
146401 [host=rochester1]
146429 pass 933ebad2470a169504799a1d95b8e410bd9847ef c081788f80f828a021bb192411da05133bd13957
146420 fail 933ebad2470a169504799a1d95b8e410bd9847ef 2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
146425 pass 933ebad2470a169504799a1d95b8e410bd9847ef 1eeedaf5a0d9ed6324f3bd5b700bb22eb4355341
146426 fail 933ebad2470a169504799a1d95b8e410bd9847ef 2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
146428 pass 933ebad2470a169504799a1d95b8e410bd9847ef 6cb4b01c033b7abc3e7175501330dfb01fb09da5
146430 pass 933ebad2470a169504799a1d95b8e410bd9847ef c5bcf30b2cfaec6bb1924e96d77134121d023692
146431 pass 933ebad2470a169504799a1d95b8e410bd9847ef 5160dbd512523d865f7271af23636aa3f3536186
146433 fail 933ebad2470a169504799a1d95b8e410bd9847ef ea22bcd030da771be18821bf4a898ed7a314eb83
146427 fail 933ebad2470a169504799a1d95b8e410bd9847ef 2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
146434 pass 933ebad2470a169504799a1d95b8e410bd9847ef 5160dbd512523d865f7271af23636aa3f3536186
146436 fail 933ebad2470a169504799a1d95b8e410bd9847ef ea22bcd030da771be18821bf4a898ed7a314eb83
146435 [host=rochester1]
146437 pass 933ebad2470a169504799a1d95b8e410bd9847ef 5160dbd512523d865f7271af23636aa3f3536186
146440 [host=rochester1]
146441 [host=rochester1]
146442 [host=rochester1]
146443 [host=rochester1]
146444 [host=rochester1]
146438 fail 933ebad2470a169504799a1d95b8e410bd9847ef 2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
146446 [host=rochester1]
146449 fail 933ebad2470a169504799a1d95b8e410bd9847ef ea22bcd030da771be18821bf4a898ed7a314eb83
Searching for interesting versions
Result found: flight 146218 (pass), for basis pass
Result found: flight 146420 (fail), for basis failure
Repro found: flight 146425 (pass), for basis pass
Repro found: flight 146426 (fail), for basis failure
0 revisions at 933ebad2470a169504799a1d95b8e410bd9847ef 5160dbd512523d865f7271af23636aa3f3536186
No revisions left to test, checking graph state.
Result found: flight 146431 (pass), for last pass
Result found: flight 146433 (fail), for first failure
Repro found: flight 146434 (pass), for last pass
Repro found: flight 146436 (fail), for first failure
Repro found: flight 146437 (pass), for last pass
Repro found: flight 146449 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: ea22bcd030da771be18821bf4a898ed7a314eb83
Bug not present: 5160dbd512523d865f7271af23636aa3f3536186
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/146449/
commit ea22bcd030da771be18821bf4a898ed7a314eb83
Author: Alexandru Stefan ISAILA <aisaila@bitdefender.com>
Date: Fri Jan 17 13:31:30 2020 +0000
x86/altp2m: Add hypercall to set a range of sve bits
By default the sve bits are not set.
This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
to set a range of sve bits.
The core function, p2m_set_suppress_ve_multi(), does not break in case
of a error and it is doing a best effort for setting the bits in the
given range. A check for continuation is made in order to have
preemption on large ranges.
The gfn of the first error is stored in
xen_hvm_altp2m_suppress_ve_multi.first_error_gfn and the error code is
stored in xen_hvm_altp2m_suppress_ve_multi.first_error.
If no error occurred the values will be 0.
Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Petre Pircalabu <ppircalabu@bitdefender.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Revision graph left in /home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.{dot,ps,png,html,svg}.
----------------------------------------
146449: tolerable ALL FAIL
flight 146449 xen-unstable-smoke real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/146449/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
build-arm64-xsm 6 xen-build fail baseline untested
jobs:
build-arm64-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] 7+ messages in thread* [Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm
@ 2020-01-14 17:18 osstest service owner
0 siblings, 0 replies; 7+ messages in thread
From: osstest service owner @ 2020-01-14 17:18 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
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: 892b9dcebdb7f646657e11cfdd95a385107bbefa
Bug not present: 03bfe526ecadc86f31eda433b91dc90be0563919
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/146088/
commit 892b9dcebdb7f646657e11cfdd95a385107bbefa
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Jan 14 12:03:47 2020 +0100
IRQ: u16 is too narrow for an event channel number
FIFO event channels allow ports up to 2^17, so we need to use a wider
field in struct pirq. Move "masked" such that it may share the 8-byte
slot with struct arch_pirq on 64-bit arches, rather than leaving a
7-byte hole in all cases.
Take the opportunity and also add a comment regarding "arch" placement
within the structure.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build --summary-out=tmp/146088.bisection-summary --basis-template=146048 --blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build
Searching for failure / basis pass:
146068 fail [host=rochester1] / 146048 ok.
Failure / basis pass flights: 146068 / 146048
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 933ebad2470a169504799a1d95b8e410bd9847ef 101398e1f81ca7a4f45ab54c4d0c4fee7b3a7bd8
Basis pass 933ebad2470a169504799a1d95b8e410bd9847ef 03bfe526ecadc86f31eda433b91dc90be0563919
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e410bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef git://xenbits.xen.org/xen.git#03bfe526ecadc86f31eda433b91dc90be0563919-101398e1f81ca7a4f45ab54c4d0c4fee7b3a7bd8
Loaded 5001 nodes in revision graph
Searching for test results:
146048 pass 933ebad2470a169504799a1d95b8e410bd9847ef 03bfe526ecadc86f31eda433b91dc90be0563919
146083 pass 933ebad2470a169504799a1d95b8e410bd9847ef 03bfe526ecadc86f31eda433b91dc90be0563919
146080 fail 933ebad2470a169504799a1d95b8e410bd9847ef 101398e1f81ca7a4f45ab54c4d0c4fee7b3a7bd8
146068 fail 933ebad2470a169504799a1d95b8e410bd9847ef 101398e1f81ca7a4f45ab54c4d0c4fee7b3a7bd8
146074 pass 933ebad2470a169504799a1d95b8e410bd9847ef 03bfe526ecadc86f31eda433b91dc90be0563919
146082 fail 933ebad2470a169504799a1d95b8e410bd9847ef 892b9dcebdb7f646657e11cfdd95a385107bbefa
146088 fail 933ebad2470a169504799a1d95b8e410bd9847ef 892b9dcebdb7f646657e11cfdd95a385107bbefa
146086 fail 933ebad2470a169504799a1d95b8e410bd9847ef 892b9dcebdb7f646657e11cfdd95a385107bbefa
146087 pass 933ebad2470a169504799a1d95b8e410bd9847ef 03bfe526ecadc86f31eda433b91dc90be0563919
Searching for interesting versions
Result found: flight 146048 (pass), for basis pass
Result found: flight 146068 (fail), for basis failure
Repro found: flight 146074 (pass), for basis pass
Repro found: flight 146080 (fail), for basis failure
0 revisions at 933ebad2470a169504799a1d95b8e410bd9847ef 03bfe526ecadc86f31eda433b91dc90be0563919
No revisions left to test, checking graph state.
Result found: flight 146048 (pass), for last pass
Result found: flight 146082 (fail), for first failure
Repro found: flight 146083 (pass), for last pass
Repro found: flight 146086 (fail), for first failure
Repro found: flight 146087 (pass), for last pass
Repro found: flight 146088 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 892b9dcebdb7f646657e11cfdd95a385107bbefa
Bug not present: 03bfe526ecadc86f31eda433b91dc90be0563919
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/146088/
commit 892b9dcebdb7f646657e11cfdd95a385107bbefa
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Jan 14 12:03:47 2020 +0100
IRQ: u16 is too narrow for an event channel number
FIFO event channels allow ports up to 2^17, so we need to use a wider
field in struct pirq. Move "masked" such that it may share the 8-byte
slot with struct arch_pirq on 64-bit arches, rather than leaving a
7-byte hole in all cases.
Take the opportunity and also add a comment regarding "arch" placement
within the structure.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Revision graph left in /home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.{dot,ps,png,html,svg}.
----------------------------------------
146088: tolerable ALL FAIL
flight 146088 xen-unstable-smoke real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/146088/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
build-arm64-xsm 6 xen-build fail baseline untested
jobs:
build-arm64-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] 7+ messages in thread* [Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm
@ 2019-12-20 7:08 osstest service owner
0 siblings, 0 replies; 7+ messages in thread
From: osstest service owner @ 2019-12-20 7:08 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build/dist-test
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: 25164571fc11ed3010c5885a98a68fac3b891d33
Bug not present: 0cd791c499bdc698d14a24050ec56d60b45732e0
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/145004/
commit 25164571fc11ed3010c5885a98a68fac3b891d33
Merge: 0cd791c499 5083e0ff93
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu Dec 19 20:16:43 2019 -0500
Merge branch 'livepatch.aws.v6' into staging
* livepatch.aws.v6:
livepatch: Add metadata runtime retrieval mechanism
livepatch: Handle arbitrary size names with the list operation
livepatch: Add support for modules .modinfo section metadata
livepatch: Add support for inline asm livepatching expectations
livepatch: Add per-function applied/reverted state tracking marker
livepatch: Do not enforce ELF_LIVEPATCH_FUNC section presence
livepatch: Add support for apply|revert action replacement hooks
livepatch: Implement pre-|post- apply|revert hooks
livepatch: Export payload structure via livepatch_payload.h
livepatch: Allow to override inter-modules buildid dependency
livepatch: Always check hypervisor build ID upon livepatch upload
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
commit 5083e0ff939d149860db40e0da54ea2048749471
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:08:00 2019 +0000
livepatch: Add metadata runtime retrieval mechanism
Extend the livepatch list operation to fetch also payloads' metadata.
This is achieved by extending the sysctl list interface with 2 extra
guest handles:
* metadata - an array of arbitrary size strings
* metadata_len - an array of metadata strings' lengths (uin32_t each)
Payloads' metadata is a string of arbitrary size and does not have an
upper bound limit. It may also vary in size between payloads.
In order to let the userland allocate enough space for the incoming
data add a metadata total size field to the list sysctl operation and
fill it with total size of all payloads' metadata.
Extend the libxc to handle the metadata back-to-back data transfers
as well as metadata length array data transfers.
The xen-livepatch userland tool is extended to always display the
metadata for each received module. The metadata is received with the
following format: key=value\0key=value\0...key=value\0. The format is
modified to the following one: key=value;key=value;...key=value.
The new format allows to easily parse the metadata for a given module
by a machine.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Reviewed-by: Norbert Manthey <nmanthey@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit b145b4a39c1324186b1b43313a9fefc19b7aa43f
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:59 2019 +0000
livepatch: Handle arbitrary size names with the list operation
The payloads' name strings can be of arbitrary size (typically small
with an upper bound of XEN_LIVEPATCH_NAME_SIZE).
Current implementation of the list operation interface allows to copy
names in the XEN_LIVEPATCH_NAME_SIZE chunks regardless of its actual
size and enforces space allocation requirements on userland tools.
To unify and simplify the interface, handle the name strings of
arbitrary size by copying them in adhering chunks to the userland.
In order to let the userland allocate enough space for the incoming
data add an auxiliary interface xc_livepatch_list_get_sizes() that
provides the current number of payload entries and the total size of
all name strings. This is achieved by extending the sysctl list
interface with an extra fields: name_total_size.
The xc_livepatch_list_get_sizes() issues the livepatch sysctl list
operation with the nr field set to 0. In this mode the operation
returns the number of payload entries and calculates the total sizes
for all payloads' names.
When the sysctl operation is issued with a non-zero nr field (for
instance with a value obtained earlier with the prior call to the
xc_livepatch_list_get_sizes()) the new field name_total_size provides
the total size of actually copied data.
Extend the libxc to handle the name back-to-back data transfers.
The xen-livepatch tool is modified to start the list operation with a
call to the xc_livepatch_list_get_sizes() to obtain the actual number
of payloads as well as the necessary space for names.
The tool now always requests the actual number of entries and leaves
the preemption handling to the libxc routine. The libxc still returns
'done' and 'left' parameters with the same semantic allowing the tool
to detect anomalies and react to them. At the moment it is expected
that the tool receives the exact number of entries as requested.
The xen-livepatch tool has been also modified to handle the name
back-to-back transfers correctly.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit 4848297ad42135ee8e7e1e6e14b3855ceaf3eb08
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:58 2019 +0000
livepatch: Add support for modules .modinfo section metadata
Having detailed livepatch metadata helps to properly identify module's
origin and version. It also allows to keep track of the history of
livepatch loads in the system (at least within dmesg buffer size
limits).
The livepatch metadata are embedded in a form of .modinfo section.
Each such section contains data of the following format:
key=value\0key=value\0...key=value\0
The .modinfo section may be generated and appended to the resulting
livepatch ELF file optionally as an extra step of a higher level
livepatch build system.
The metadata section pointer and the section length is stored in the
livepatch payload structure and is used to display the content upon
livepatch apply operation.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Leonard Foerster <foersleo@amazon.de>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Reviewed-by: Norbert Manthey <nmanthey@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit 8e24c887887a95cb2dda0017569ed19b65670152
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:57 2019 +0000
livepatch: Add support for inline asm livepatching expectations
This is the initial implementation of the expectations enhancement
to improve inline asm livepatching.
Expectations are designed as optional feature, since the main use of
them is planned for inline asm livepatching. The flag enabled allows
to control the expectation state.
Each expectation has data and len fields that describe the data
that is expected to be found at a given patching (old_addr) location.
The len must not exceed the data array size. The data array size
follows the size of the opaque array, since the opaque array holds
the original data and therefore must match what is specified in the
expectation (if enabled).
The payload structure is modified as each expectation structure is
part of the livepatch_func structure and hence extends the payload.
Each expectation is checked prior to the apply action (i.e. as late
as possible to check against the most current state of the code).
For the replace action a new payload's expectations are checked AFTER
all applied payloads are successfully reverted, but BEFORE new payload
is applied. That breaks the replace action's atomicity and in case of
an expectation check failure would leave a system with all payloads
reverted. That is obviously insecure. Use it with caution and act
upon replace errors!
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Reviewed-by: Norbert Manthey <nmanthey@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit 6047104c3ccc50205464a9b6a90daa85d21a4798
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:56 2019 +0000
livepatch: Add per-function applied/reverted state tracking marker
Livepatch only tracks an entire payload applied/reverted state. But,
with an option to supply the apply_payload() and/or revert_payload()
functions as optional hooks, it becomes possible to intermix the
execution of the original apply_payload()/revert_payload() functions
with their dynamically supplied counterparts.
It is important then to track the current state of every function
being patched and prevent situations of unintentional double-apply
or unapplied revert.
To support that, it is necessary to extend public interface of the
livepatch. The struct livepatch_func gets additional field holding
the applied/reverted state marker.
To reflect the livepatch payload ABI change, bump the version flag
LIVEPATCH_PAYLOAD_VERSION up to 2.
[And also update the top of the design document]
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit 76b3d4098a92a323a43bc250c67c721c1eed0acb
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:55 2019 +0000
livepatch: Do not enforce ELF_LIVEPATCH_FUNC section presence
With default implementation the ELF_LIVEPATCH_FUNC section containing
all functions to be replaced or added must be part of the livepatch
payload, otherwise the payload is rejected (with -EINVAL).
However, with the extended hooks implementation, a livepatch may be
constructed of only hooks to perform certain actions without any code
to be added or replaced.
Therefore, do not always expect the functions section and allow it to
be missing, provided there is at least one section containing hooks
present. The functions section, when present in a payload, must be a
single, non-empty section.
Check also all extended hooks sections if they are a single, non-empty
sections each.
At least one of the functions or hooks section must be present in a
valid payload.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit ef87efee9d38b61624f25c1a056d386a70ba99aa
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:54 2019 +0000
livepatch: Add support for apply|revert action replacement hooks
By default, in the quiescing zone, a livepatch payload is applied with
apply_payload() and reverted with revert_payload() functions. Both of
the functions receive the payload struct pointer as a parameter. The
functions are also a place where standard 'load' and 'unload' module
hooks are executed.
To increase livepatching system's agility and provide more flexible
long-term livepatch solution, allow to overwrite the default apply
and revert action functions with hook-like supplied alternatives.
The alternative functions are optional and the default functions are
used by default.
Since the alternative functions have direct access to the livepatch
payload structure, they can better control context of the 'load' and
'unload' hooks execution as well as exact instructions replacement
workflows. They can be also easily extended to support extra features
in the future.
To simplify the alternative function generation move code responsible
for payload and livepatch region registration outside of the function.
That way it is guaranteed that the registration step occurs even for
newly supplied functions.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Petre Eftime <epetre@amazon.com>
Reviewed-by: Martin Pohlack <mpohlack@amazon.com>
Reviewed-by: Norbert Manthey <nmanthey@amazon.com>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Bjoern Doebel <doebel@amazon.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit 8313c864fa95074c2176f19af711b7e13bf20504
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:53 2019 +0000
livepatch: Implement pre-|post- apply|revert hooks
This is an implementation of 4 new livepatch module vetoing hooks,
that can be optionally supplied along with modules.
Hooks that currently exists in the livepatch mechanism aren't agile
enough and have various limitations:
* run only from within a quiescing zone
* cannot conditionally prevent applying or reverting
* do not have access to the module context
To address these limitations the following has been implemented:
1) pre-apply hook
runs before the apply action is scheduled for execution. Its main
purpose is to prevent from applying a livepatch when certain
expected conditions aren't met or when mutating actions implemented
in the hook fail or cannot be executed.
2) post-apply hook
runs after the apply action has been executed and quiescing zone
exited. Its main purpose is to provide an ability to follow-up on
actions performed by the pre- hook, when module application was
successful or undo certain preparation steps of the pre- hook in
case of a failure. The success/failure error code is provided to
the post- hooks via the rc field of the payload structure.
3) pre-revert hook
runs before the revert action is scheduled for execution. Its main
purpose is to prevent from reverting a livepatch when certain
expected conditions aren't met or when mutating actions implemented
in the hook fail or cannot be executed.
4) post-revert hook
runs after the revert action has been executed and quiescing zone
exited. Its main purpose is to perform cleanup of all previously
executed mutating actions in order to restore the original system
state from before the current module application.
The success/failure error code is provided to the post- hooks via
the rc field of the payload structure.
The replace action performs atomically the following actions:
- revert all applied modules
- apply a single replacement module.
With the vetoing hooks in place various inter-hook dependencies may
arise. Also, during the revert part of the operation certain vetoing
hooks may detect failing conditions that previously were satisfied.
That could in turn lead to situation when the revert part must be
rolled back with all the pre- and post- hooks re-applied, which again
can't be guaranteed to always succeed.
The simplest response to this complication is to disallow the replace
action completely on modules with vetoing hooks.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Petre Eftime <epetre@amazon.com>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Reviewed-by: Norbert Manthey <nmanthey@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit 3bafe4a06051de1d7abfffe77c8b9cb58594f39f
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:52 2019 +0000
livepatch: Export payload structure via livepatch_payload.h
The payload structure will be used by the new hooks implementation and
therefore its definition has to be exported via the livepatch_payload
header.
The new hooks will make use of the payload structure fields and the
hooks' pointers will also be defined in the payload structure, so
the structure along with all field definitions needs to be available
to the code being patched in.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Eslam Elnikety <elnikety@amazon.de>
Reviewed-by: Leonard Foerster <foersleo@amazon.de>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
commit b274989b610d37f0775e93c08343d30ec267a80f
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:51 2019 +0000
livepatch: Allow to override inter-modules buildid dependency
By default Livepatch enforces the following buildid-based dependency
chain between livepatch modules:
1) first module depends on given hypervisor buildid
2) every consecutive module depends on previous module's buildid
This way proper livepatch stack order is maintained and enforced.
While it is important for production livepatches it limits agility and
blocks usage of testing or debug livepatches. These kinds of livepatch
modules are typically expected to be loaded at any time irrespective
of current state of the modules stack.
To enable testing and debug livepatches allow user dynamically ignore
the inter-modules dependency. In this case only hypervisor buildid
match is verified and enforced.
To allow userland pass additional paremeters for livepatch actions
add support for action flags.
Each of the apply, revert, unload and revert action gets additional
32-bit parameter 'flags' where extra flags can be applied in a mask
form.
Initially only one flag '--nodeps' is added for the apply action.
This flag modifies the default buildid dependency check as described
above.
The global sysctl interface input flag parameter is defined with a
single corresponding flag macro:
LIVEPATCH_ACTION_APPLY_NODEPS (1 << 0)
The userland xen-livepatch tool is modified to support the '--nodeps'
flag for apply and load commands. A general mechanism for specifying
more flags in the future for apply and other action is however added.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Eslam Elnikety <elnikety@amazon.de>
Reviewed-by: Petre Eftime <epetre@amazon.com>
Reviewed-by: Leonard Foerster <foersleo@amazon.de>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Reviewed-by: Norbert Manthey <nmanthey@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit 879615f5db1d0a86afd99a67d284a8df6fd85be4
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:50 2019 +0000
livepatch: Always check hypervisor build ID upon livepatch upload
This change is part of a independant stacked livepatch modules
feature. This feature allows to bypass dependencies between modules
upon loading, but still verifies Xen build ID matching.
In order to prevent (up)loading any livepatches built for different
hypervisor version as indicated by the Xen Build ID, add checking for
the payload's vs Xen's build id match.
To achieve that embed into every livepatch another section with a
dedicated hypervisor build id in it. After the payload is loaded and
the .livepatch.xen_depends section becomes available, perform the
check and reject the payload if there is no match.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Eslam Elnikety <elnikety@amazon.de>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build--dist-test.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-smoke/build-arm64-xsm.xen-build--dist-test --summary-out=tmp/145004.bisection-summary --basis-template=144983 --blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build/dist-test
Searching for failure / basis pass:
144991 fail [host=laxton1] / 144983 ok.
Failure / basis pass flights: 144991 / 144983
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 933ebad2470a169504799a1d95b8e410bd9847ef 25164571fc11ed3010c5885a98a68fac3b891d33
Basis pass 933ebad2470a169504799a1d95b8e410bd9847ef 0cd791c499bdc698d14a24050ec56d60b45732e0
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e410bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef git://xenbits.xen.org/xen.git#0cd791c499bdc698d14a24050ec56d60b45732e0-25164571fc11ed3010c5885a98a68fac3b891d33
Loaded 5001 nodes in revision graph
Searching for test results:
144983 pass 933ebad2470a169504799a1d95b8e410bd9847ef 0cd791c499bdc698d14a24050ec56d60b45732e0
144991 fail 933ebad2470a169504799a1d95b8e410bd9847ef 25164571fc11ed3010c5885a98a68fac3b891d33
144997 pass 933ebad2470a169504799a1d95b8e410bd9847ef 0cd791c499bdc698d14a24050ec56d60b45732e0
145001 fail 933ebad2470a169504799a1d95b8e410bd9847ef 25164571fc11ed3010c5885a98a68fac3b891d33
145003 pass 933ebad2470a169504799a1d95b8e410bd9847ef 0cd791c499bdc698d14a24050ec56d60b45732e0
145004 fail 933ebad2470a169504799a1d95b8e410bd9847ef 25164571fc11ed3010c5885a98a68fac3b891d33
Searching for interesting versions
Result found: flight 144983 (pass), for basis pass
Result found: flight 144991 (fail), for basis failure
Repro found: flight 144997 (pass), for basis pass
Repro found: flight 145001 (fail), for basis failure
0 revisions at 933ebad2470a169504799a1d95b8e410bd9847ef 0cd791c499bdc698d14a24050ec56d60b45732e0
No revisions left to test, checking graph state.
Result found: flight 144983 (pass), for last pass
Result found: flight 144991 (fail), for first failure
Repro found: flight 144997 (pass), for last pass
Repro found: flight 145001 (fail), for first failure
Repro found: flight 145003 (pass), for last pass
Repro found: flight 145004 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 25164571fc11ed3010c5885a98a68fac3b891d33
Bug not present: 0cd791c499bdc698d14a24050ec56d60b45732e0
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/145004/
commit 25164571fc11ed3010c5885a98a68fac3b891d33
Merge: 0cd791c499 5083e0ff93
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu Dec 19 20:16:43 2019 -0500
Merge branch 'livepatch.aws.v6' into staging
* livepatch.aws.v6:
livepatch: Add metadata runtime retrieval mechanism
livepatch: Handle arbitrary size names with the list operation
livepatch: Add support for modules .modinfo section metadata
livepatch: Add support for inline asm livepatching expectations
livepatch: Add per-function applied/reverted state tracking marker
livepatch: Do not enforce ELF_LIVEPATCH_FUNC section presence
livepatch: Add support for apply|revert action replacement hooks
livepatch: Implement pre-|post- apply|revert hooks
livepatch: Export payload structure via livepatch_payload.h
livepatch: Allow to override inter-modules buildid dependency
livepatch: Always check hypervisor build ID upon livepatch upload
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
commit 5083e0ff939d149860db40e0da54ea2048749471
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:08:00 2019 +0000
livepatch: Add metadata runtime retrieval mechanism
Extend the livepatch list operation to fetch also payloads' metadata.
This is achieved by extending the sysctl list interface with 2 extra
guest handles:
* metadata - an array of arbitrary size strings
* metadata_len - an array of metadata strings' lengths (uin32_t each)
Payloads' metadata is a string of arbitrary size and does not have an
upper bound limit. It may also vary in size between payloads.
In order to let the userland allocate enough space for the incoming
data add a metadata total size field to the list sysctl operation and
fill it with total size of all payloads' metadata.
Extend the libxc to handle the metadata back-to-back data transfers
as well as metadata length array data transfers.
The xen-livepatch userland tool is extended to always display the
metadata for each received module. The metadata is received with the
following format: key=value\0key=value\0...key=value\0. The format is
modified to the following one: key=value;key=value;...key=value.
The new format allows to easily parse the metadata for a given module
by a machine.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Reviewed-by: Norbert Manthey <nmanthey@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit b145b4a39c1324186b1b43313a9fefc19b7aa43f
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:59 2019 +0000
livepatch: Handle arbitrary size names with the list operation
The payloads' name strings can be of arbitrary size (typically small
with an upper bound of XEN_LIVEPATCH_NAME_SIZE).
Current implementation of the list operation interface allows to copy
names in the XEN_LIVEPATCH_NAME_SIZE chunks regardless of its actual
size and enforces space allocation requirements on userland tools.
To unify and simplify the interface, handle the name strings of
arbitrary size by copying them in adhering chunks to the userland.
In order to let the userland allocate enough space for the incoming
data add an auxiliary interface xc_livepatch_list_get_sizes() that
provides the current number of payload entries and the total size of
all name strings. This is achieved by extending the sysctl list
interface with an extra fields: name_total_size.
The xc_livepatch_list_get_sizes() issues the livepatch sysctl list
operation with the nr field set to 0. In this mode the operation
returns the number of payload entries and calculates the total sizes
for all payloads' names.
When the sysctl operation is issued with a non-zero nr field (for
instance with a value obtained earlier with the prior call to the
xc_livepatch_list_get_sizes()) the new field name_total_size provides
the total size of actually copied data.
Extend the libxc to handle the name back-to-back data transfers.
The xen-livepatch tool is modified to start the list operation with a
call to the xc_livepatch_list_get_sizes() to obtain the actual number
of payloads as well as the necessary space for names.
The tool now always requests the actual number of entries and leaves
the preemption handling to the libxc routine. The libxc still returns
'done' and 'left' parameters with the same semantic allowing the tool
to detect anomalies and react to them. At the moment it is expected
that the tool receives the exact number of entries as requested.
The xen-livepatch tool has been also modified to handle the name
back-to-back transfers correctly.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit 4848297ad42135ee8e7e1e6e14b3855ceaf3eb08
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:58 2019 +0000
livepatch: Add support for modules .modinfo section metadata
Having detailed livepatch metadata helps to properly identify module's
origin and version. It also allows to keep track of the history of
livepatch loads in the system (at least within dmesg buffer size
limits).
The livepatch metadata are embedded in a form of .modinfo section.
Each such section contains data of the following format:
key=value\0key=value\0...key=value\0
The .modinfo section may be generated and appended to the resulting
livepatch ELF file optionally as an extra step of a higher level
livepatch build system.
The metadata section pointer and the section length is stored in the
livepatch payload structure and is used to display the content upon
livepatch apply operation.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Leonard Foerster <foersleo@amazon.de>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Reviewed-by: Norbert Manthey <nmanthey@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit 8e24c887887a95cb2dda0017569ed19b65670152
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:57 2019 +0000
livepatch: Add support for inline asm livepatching expectations
This is the initial implementation of the expectations enhancement
to improve inline asm livepatching.
Expectations are designed as optional feature, since the main use of
them is planned for inline asm livepatching. The flag enabled allows
to control the expectation state.
Each expectation has data and len fields that describe the data
that is expected to be found at a given patching (old_addr) location.
The len must not exceed the data array size. The data array size
follows the size of the opaque array, since the opaque array holds
the original data and therefore must match what is specified in the
expectation (if enabled).
The payload structure is modified as each expectation structure is
part of the livepatch_func structure and hence extends the payload.
Each expectation is checked prior to the apply action (i.e. as late
as possible to check against the most current state of the code).
For the replace action a new payload's expectations are checked AFTER
all applied payloads are successfully reverted, but BEFORE new payload
is applied. That breaks the replace action's atomicity and in case of
an expectation check failure would leave a system with all payloads
reverted. That is obviously insecure. Use it with caution and act
upon replace errors!
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Reviewed-by: Norbert Manthey <nmanthey@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit 6047104c3ccc50205464a9b6a90daa85d21a4798
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:56 2019 +0000
livepatch: Add per-function applied/reverted state tracking marker
Livepatch only tracks an entire payload applied/reverted state. But,
with an option to supply the apply_payload() and/or revert_payload()
functions as optional hooks, it becomes possible to intermix the
execution of the original apply_payload()/revert_payload() functions
with their dynamically supplied counterparts.
It is important then to track the current state of every function
being patched and prevent situations of unintentional double-apply
or unapplied revert.
To support that, it is necessary to extend public interface of the
livepatch. The struct livepatch_func gets additional field holding
the applied/reverted state marker.
To reflect the livepatch payload ABI change, bump the version flag
LIVEPATCH_PAYLOAD_VERSION up to 2.
[And also update the top of the design document]
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit 76b3d4098a92a323a43bc250c67c721c1eed0acb
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:55 2019 +0000
livepatch: Do not enforce ELF_LIVEPATCH_FUNC section presence
With default implementation the ELF_LIVEPATCH_FUNC section containing
all functions to be replaced or added must be part of the livepatch
payload, otherwise the payload is rejected (with -EINVAL).
However, with the extended hooks implementation, a livepatch may be
constructed of only hooks to perform certain actions without any code
to be added or replaced.
Therefore, do not always expect the functions section and allow it to
be missing, provided there is at least one section containing hooks
present. The functions section, when present in a payload, must be a
single, non-empty section.
Check also all extended hooks sections if they are a single, non-empty
sections each.
At least one of the functions or hooks section must be present in a
valid payload.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit ef87efee9d38b61624f25c1a056d386a70ba99aa
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:54 2019 +0000
livepatch: Add support for apply|revert action replacement hooks
By default, in the quiescing zone, a livepatch payload is applied with
apply_payload() and reverted with revert_payload() functions. Both of
the functions receive the payload struct pointer as a parameter. The
functions are also a place where standard 'load' and 'unload' module
hooks are executed.
To increase livepatching system's agility and provide more flexible
long-term livepatch solution, allow to overwrite the default apply
and revert action functions with hook-like supplied alternatives.
The alternative functions are optional and the default functions are
used by default.
Since the alternative functions have direct access to the livepatch
payload structure, they can better control context of the 'load' and
'unload' hooks execution as well as exact instructions replacement
workflows. They can be also easily extended to support extra features
in the future.
To simplify the alternative function generation move code responsible
for payload and livepatch region registration outside of the function.
That way it is guaranteed that the registration step occurs even for
newly supplied functions.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Petre Eftime <epetre@amazon.com>
Reviewed-by: Martin Pohlack <mpohlack@amazon.com>
Reviewed-by: Norbert Manthey <nmanthey@amazon.com>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Bjoern Doebel <doebel@amazon.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit 8313c864fa95074c2176f19af711b7e13bf20504
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:53 2019 +0000
livepatch: Implement pre-|post- apply|revert hooks
This is an implementation of 4 new livepatch module vetoing hooks,
that can be optionally supplied along with modules.
Hooks that currently exists in the livepatch mechanism aren't agile
enough and have various limitations:
* run only from within a quiescing zone
* cannot conditionally prevent applying or reverting
* do not have access to the module context
To address these limitations the following has been implemented:
1) pre-apply hook
runs before the apply action is scheduled for execution. Its main
purpose is to prevent from applying a livepatch when certain
expected conditions aren't met or when mutating actions implemented
in the hook fail or cannot be executed.
2) post-apply hook
runs after the apply action has been executed and quiescing zone
exited. Its main purpose is to provide an ability to follow-up on
actions performed by the pre- hook, when module application was
successful or undo certain preparation steps of the pre- hook in
case of a failure. The success/failure error code is provided to
the post- hooks via the rc field of the payload structure.
3) pre-revert hook
runs before the revert action is scheduled for execution. Its main
purpose is to prevent from reverting a livepatch when certain
expected conditions aren't met or when mutating actions implemented
in the hook fail or cannot be executed.
4) post-revert hook
runs after the revert action has been executed and quiescing zone
exited. Its main purpose is to perform cleanup of all previously
executed mutating actions in order to restore the original system
state from before the current module application.
The success/failure error code is provided to the post- hooks via
the rc field of the payload structure.
The replace action performs atomically the following actions:
- revert all applied modules
- apply a single replacement module.
With the vetoing hooks in place various inter-hook dependencies may
arise. Also, during the revert part of the operation certain vetoing
hooks may detect failing conditions that previously were satisfied.
That could in turn lead to situation when the revert part must be
rolled back with all the pre- and post- hooks re-applied, which again
can't be guaranteed to always succeed.
The simplest response to this complication is to disallow the replace
action completely on modules with vetoing hooks.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Petre Eftime <epetre@amazon.com>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Reviewed-by: Norbert Manthey <nmanthey@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit 3bafe4a06051de1d7abfffe77c8b9cb58594f39f
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:52 2019 +0000
livepatch: Export payload structure via livepatch_payload.h
The payload structure will be used by the new hooks implementation and
therefore its definition has to be exported via the livepatch_payload
header.
The new hooks will make use of the payload structure fields and the
hooks' pointers will also be defined in the payload structure, so
the structure along with all field definitions needs to be available
to the code being patched in.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Eslam Elnikety <elnikety@amazon.de>
Reviewed-by: Leonard Foerster <foersleo@amazon.de>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
commit b274989b610d37f0775e93c08343d30ec267a80f
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:51 2019 +0000
livepatch: Allow to override inter-modules buildid dependency
By default Livepatch enforces the following buildid-based dependency
chain between livepatch modules:
1) first module depends on given hypervisor buildid
2) every consecutive module depends on previous module's buildid
This way proper livepatch stack order is maintained and enforced.
While it is important for production livepatches it limits agility and
blocks usage of testing or debug livepatches. These kinds of livepatch
modules are typically expected to be loaded at any time irrespective
of current state of the modules stack.
To enable testing and debug livepatches allow user dynamically ignore
the inter-modules dependency. In this case only hypervisor buildid
match is verified and enforced.
To allow userland pass additional paremeters for livepatch actions
add support for action flags.
Each of the apply, revert, unload and revert action gets additional
32-bit parameter 'flags' where extra flags can be applied in a mask
form.
Initially only one flag '--nodeps' is added for the apply action.
This flag modifies the default buildid dependency check as described
above.
The global sysctl interface input flag parameter is defined with a
single corresponding flag macro:
LIVEPATCH_ACTION_APPLY_NODEPS (1 << 0)
The userland xen-livepatch tool is modified to support the '--nodeps'
flag for apply and load commands. A general mechanism for specifying
more flags in the future for apply and other action is however added.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Eslam Elnikety <elnikety@amazon.de>
Reviewed-by: Petre Eftime <epetre@amazon.com>
Reviewed-by: Leonard Foerster <foersleo@amazon.de>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Reviewed-by: Norbert Manthey <nmanthey@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
commit 879615f5db1d0a86afd99a67d284a8df6fd85be4
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date: Tue Nov 26 10:07:50 2019 +0000
livepatch: Always check hypervisor build ID upon livepatch upload
This change is part of a independant stacked livepatch modules
feature. This feature allows to bypass dependencies between modules
upon loading, but still verifies Xen build ID matching.
In order to prevent (up)loading any livepatches built for different
hypervisor version as indicated by the Xen Build ID, add checking for
the payload's vs Xen's build id match.
To achieve that embed into every livepatch another section with a
dedicated hypervisor build id in it. After the payload is loaded and
the .livepatch.xen_depends section becomes available, perform the
check and reject the payload if there is no match.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Eslam Elnikety <elnikety@amazon.de>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Revision graph left in /home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build--dist-test.{dot,ps,png,html,svg}.
----------------------------------------
145004: tolerable all pass
flight 145004 xen-unstable-smoke real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/145004/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
build-arm64-xsm 7 xen-build/dist-test fail baseline untested
jobs:
build-arm64-xsm pass
------------------------------------------------------------
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] 7+ messages in thread* [Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm
@ 2019-09-20 19:42 osstest service owner
0 siblings, 0 replies; 7+ messages in thread
From: osstest service owner @ 2019-09-20 19:42 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
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: edaa631ddcee665cdfae1cf6bc7492c791e01ef4
Bug not present: d6c7cd918adcfdc8ae41cf89e6a47ef4e4d3c1f6
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/141535/
commit edaa631ddcee665cdfae1cf6bc7492c791e01ef4
Author: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu May 23 11:54:52 2019 +0100
libxl: Make libxl_domain_unpause async
libxl_domain_unpause needs to make QMP calls, which are asynchronous,
change the API to reflect that.
Do the same with libxl_domain_pause async, even if it will keep
completing synchronously.
Also fix some coding style issue in those functions.
Signed-off-by: Anthony PERARD <anthony.perard@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-smoke/build-arm64-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build --summary-out=tmp/141535.bisection-summary --basis-template=141253 --blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build
Searching for failure / basis pass:
141521 fail [host=laxton1] / 141498 [host=rochester1] 141494 [host=laxton0] 141489 [host=laxton0] 141485 [host=rochester0] 141480 [host=laxton0] 141474 [host=laxton0] 141470 ok.
Failure / basis pass flights: 141521 / 141470
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest cef9660618a880ced798375a0fd16a8ad80bd0f0 ae84f55353475f569daddb9a81ac0a6bc7772c90
Basis pass cef9660618a880ced798375a0fd16a8ad80bd0f0 88339ae94f4309888eae81a6cceac9577a319d7e
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/qemu-xen.git#cef9660618a880ced798375a0fd16a8ad80bd0f0-cef9660618a880ced798375a0fd16a8ad80bd0f0 git://xenbits.xen.org/xen.git#88339ae94f4309888eae81a6cceac9577a319d7e-ae84f55353475f569daddb9a81ac0a6bc7772c90
Loaded 1001 nodes in revision graph
Searching for test results:
141513 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 a30910bfd71a64895f0d6ddbb301cf1b5ed6c2f4
141489 [host=laxton0]
141485 [host=rochester0]
141474 [host=laxton0]
141470 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 88339ae94f4309888eae81a6cceac9577a319d7e
141498 [host=rochester1]
141480 [host=laxton0]
141494 [host=laxton0]
141514 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 a30910bfd71a64895f0d6ddbb301cf1b5ed6c2f4
141508 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 a30910bfd71a64895f0d6ddbb301cf1b5ed6c2f4
141512 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 88339ae94f4309888eae81a6cceac9577a319d7e
141515 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 8efef84cf25a93a74499a809fa655e8ceedc6f86
141517 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 dbe92a588c429324fb2b7c02eb1e1cc7027ef8e3
141518 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 3bf9b8fde811c965b425d621d2651434a95cfe4a
141522 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 edaa631ddcee665cdfae1cf6bc7492c791e01ef4
141524 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 4750c9237bd49a2179d5bd28e7259df9c46de25a
141525 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 d6c7cd918adcfdc8ae41cf89e6a47ef4e4d3c1f6
141521 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 ae84f55353475f569daddb9a81ac0a6bc7772c90
141527 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 edaa631ddcee665cdfae1cf6bc7492c791e01ef4
141528 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 88339ae94f4309888eae81a6cceac9577a319d7e
141530 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 ae84f55353475f569daddb9a81ac0a6bc7772c90
141532 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 d6c7cd918adcfdc8ae41cf89e6a47ef4e4d3c1f6
141533 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 edaa631ddcee665cdfae1cf6bc7492c791e01ef4
141534 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 d6c7cd918adcfdc8ae41cf89e6a47ef4e4d3c1f6
141535 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 edaa631ddcee665cdfae1cf6bc7492c791e01ef4
Searching for interesting versions
Result found: flight 141470 (pass), for basis pass
Result found: flight 141521 (fail), for basis failure
Repro found: flight 141528 (pass), for basis pass
Repro found: flight 141530 (fail), for basis failure
0 revisions at cef9660618a880ced798375a0fd16a8ad80bd0f0 d6c7cd918adcfdc8ae41cf89e6a47ef4e4d3c1f6
No revisions left to test, checking graph state.
Result found: flight 141525 (pass), for last pass
Result found: flight 141527 (fail), for first failure
Repro found: flight 141532 (pass), for last pass
Repro found: flight 141533 (fail), for first failure
Repro found: flight 141534 (pass), for last pass
Repro found: flight 141535 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: edaa631ddcee665cdfae1cf6bc7492c791e01ef4
Bug not present: d6c7cd918adcfdc8ae41cf89e6a47ef4e4d3c1f6
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/141535/
commit edaa631ddcee665cdfae1cf6bc7492c791e01ef4
Author: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu May 23 11:54:52 2019 +0100
libxl: Make libxl_domain_unpause async
libxl_domain_unpause needs to make QMP calls, which are asynchronous,
change the API to reflect that.
Do the same with libxl_domain_pause async, even if it will keep
completing synchronously.
Also fix some coding style issue in those functions.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Revision graph left in /home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.{dot,ps,png,html,svg}.
----------------------------------------
141535: tolerable ALL FAIL
flight 141535 xen-unstable-smoke real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/141535/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
build-arm64-xsm 6 xen-build fail baseline untested
jobs:
build-arm64-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] 7+ messages in thread* [xen-unstable-smoke bisection] complete build-arm64-xsm
@ 2019-05-21 18:46 osstest service owner
2019-05-21 18:46 ` [Xen-devel] " osstest service owner
0 siblings, 1 reply; 7+ messages in thread
From: osstest service owner @ 2019-05-21 18:46 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
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: 03957f58db8942d61f4889b6924e39d3b27a9e43
Bug not present: 57d87ee3a5d10cdba972eec3a54cd971fec1b8d2
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/136714/
commit 03957f58db8942d61f4889b6924e39d3b27a9e43
Author: Julien Grall <julien.grall@arm.com>
Date: Tue May 14 13:24:38 2019 +0100
xen/const: Extend the existing macro BIT to take a suffix in parameter
Arm currently provides two macro BIT and BIT_ULL that are only usable
in C and return respectively unsigned long and unsigned long long.
Extending the macros to deal with assembly would be a nice benefits as
it could replace the common pattern to define fields (AC(1, sfx) << X)
easier to read.
Rather than extending the two macros, it was decided to drop BIT_ULL()
and extend the macro BIT() to take a suffix (e.g U, UL, ULL) in
parameter. This would allow to use different suffix without having to
define new macros.
The new extend macro is now moved in include/xen/const.h so it can be
used by anyone in Xen and also avoid to include bitops.h in assembly
code.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build --summary-out=tmp/136714.bisection-summary --basis-template=136665 --blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build
Searching for failure / basis pass:
136687 fail [host=laxton0] / 136665 ok.
Failure / basis pass flights: 136687 / 136665
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 9cca02d8ffc23e9688a971d858e4ffdff5389b11 b915f57a49bc12e9f5fb60ce604772b09777ff0d
Basis pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 91f86f8634f99abd8f242943e62452211a09fa0a
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-9cca02d8ffc23e9688a971d858e4ffdff5389b11 git://xenbits.xen.org/xen.git#91f86f8634f99abd8f242943e62452211a09fa0a-b915f57a49bc12e9f5fb60ce604772b09777ff0d
Loaded 1001 nodes in revision graph
Searching for test results:
136705 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 57d87ee3a5d10cdba972eec3a54cd971fec1b8d2
136665 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 91f86f8634f99abd8f242943e62452211a09fa0a
136700 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 b915f57a49bc12e9f5fb60ce604772b09777ff0d
136687 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 b915f57a49bc12e9f5fb60ce604772b09777ff0d
136710 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 03957f58db8942d61f4889b6924e39d3b27a9e43
136702 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 7ad0e780857728724e59859dcc422404d4ed0c46
136708 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 03957f58db8942d61f4889b6924e39d3b27a9e43
136698 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 91f86f8634f99abd8f242943e62452211a09fa0a
136704 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 03957f58db8942d61f4889b6924e39d3b27a9e43
136709 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 57d87ee3a5d10cdba972eec3a54cd971fec1b8d2
136714 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 03957f58db8942d61f4889b6924e39d3b27a9e43
136711 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 57d87ee3a5d10cdba972eec3a54cd971fec1b8d2
Searching for interesting versions
Result found: flight 136665 (pass), for basis pass
Result found: flight 136687 (fail), for basis failure
Repro found: flight 136698 (pass), for basis pass
Repro found: flight 136700 (fail), for basis failure
0 revisions at 9cca02d8ffc23e9688a971d858e4ffdff5389b11 57d87ee3a5d10cdba972eec3a54cd971fec1b8d2
No revisions left to test, checking graph state.
Result found: flight 136705 (pass), for last pass
Result found: flight 136708 (fail), for first failure
Repro found: flight 136709 (pass), for last pass
Repro found: flight 136710 (fail), for first failure
Repro found: flight 136711 (pass), for last pass
Repro found: flight 136714 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 03957f58db8942d61f4889b6924e39d3b27a9e43
Bug not present: 57d87ee3a5d10cdba972eec3a54cd971fec1b8d2
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/136714/
commit 03957f58db8942d61f4889b6924e39d3b27a9e43
Author: Julien Grall <julien.grall@arm.com>
Date: Tue May 14 13:24:38 2019 +0100
xen/const: Extend the existing macro BIT to take a suffix in parameter
Arm currently provides two macro BIT and BIT_ULL that are only usable
in C and return respectively unsigned long and unsigned long long.
Extending the macros to deal with assembly would be a nice benefits as
it could replace the common pattern to define fields (AC(1, sfx) << X)
easier to read.
Rather than extending the two macros, it was decided to drop BIT_ULL()
and extend the macro BIT() to take a suffix (e.g U, UL, ULL) in
parameter. This would allow to use different suffix without having to
define new macros.
The new extend macro is now moved in include/xen/const.h so it can be
used by anyone in Xen and also avoid to include bitops.h in assembly
code.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Revision graph left in /home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.{dot,ps,png,html,svg}.
----------------------------------------
136714: tolerable ALL FAIL
flight 136714 xen-unstable-smoke real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/136714/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
build-arm64-xsm 6 xen-build fail baseline untested
jobs:
build-arm64-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] 7+ messages in thread* [Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm
2019-05-21 18:46 osstest service owner
@ 2019-05-21 18:46 ` osstest service owner
0 siblings, 0 replies; 7+ messages in thread
From: osstest service owner @ 2019-05-21 18:46 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
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: 03957f58db8942d61f4889b6924e39d3b27a9e43
Bug not present: 57d87ee3a5d10cdba972eec3a54cd971fec1b8d2
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/136714/
commit 03957f58db8942d61f4889b6924e39d3b27a9e43
Author: Julien Grall <julien.grall@arm.com>
Date: Tue May 14 13:24:38 2019 +0100
xen/const: Extend the existing macro BIT to take a suffix in parameter
Arm currently provides two macro BIT and BIT_ULL that are only usable
in C and return respectively unsigned long and unsigned long long.
Extending the macros to deal with assembly would be a nice benefits as
it could replace the common pattern to define fields (AC(1, sfx) << X)
easier to read.
Rather than extending the two macros, it was decided to drop BIT_ULL()
and extend the macro BIT() to take a suffix (e.g U, UL, ULL) in
parameter. This would allow to use different suffix without having to
define new macros.
The new extend macro is now moved in include/xen/const.h so it can be
used by anyone in Xen and also avoid to include bitops.h in assembly
code.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build --summary-out=tmp/136714.bisection-summary --basis-template=136665 --blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build
Searching for failure / basis pass:
136687 fail [host=laxton0] / 136665 ok.
Failure / basis pass flights: 136687 / 136665
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 9cca02d8ffc23e9688a971d858e4ffdff5389b11 b915f57a49bc12e9f5fb60ce604772b09777ff0d
Basis pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 91f86f8634f99abd8f242943e62452211a09fa0a
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-9cca02d8ffc23e9688a971d858e4ffdff5389b11 git://xenbits.xen.org/xen.git#91f86f8634f99abd8f242943e62452211a09fa0a-b915f57a49bc12e9f5fb60ce604772b09777ff0d
Loaded 1001 nodes in revision graph
Searching for test results:
136705 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 57d87ee3a5d10cdba972eec3a54cd971fec1b8d2
136665 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 91f86f8634f99abd8f242943e62452211a09fa0a
136700 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 b915f57a49bc12e9f5fb60ce604772b09777ff0d
136687 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 b915f57a49bc12e9f5fb60ce604772b09777ff0d
136710 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 03957f58db8942d61f4889b6924e39d3b27a9e43
136702 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 7ad0e780857728724e59859dcc422404d4ed0c46
136708 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 03957f58db8942d61f4889b6924e39d3b27a9e43
136698 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 91f86f8634f99abd8f242943e62452211a09fa0a
136704 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 03957f58db8942d61f4889b6924e39d3b27a9e43
136709 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 57d87ee3a5d10cdba972eec3a54cd971fec1b8d2
136714 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 03957f58db8942d61f4889b6924e39d3b27a9e43
136711 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 57d87ee3a5d10cdba972eec3a54cd971fec1b8d2
Searching for interesting versions
Result found: flight 136665 (pass), for basis pass
Result found: flight 136687 (fail), for basis failure
Repro found: flight 136698 (pass), for basis pass
Repro found: flight 136700 (fail), for basis failure
0 revisions at 9cca02d8ffc23e9688a971d858e4ffdff5389b11 57d87ee3a5d10cdba972eec3a54cd971fec1b8d2
No revisions left to test, checking graph state.
Result found: flight 136705 (pass), for last pass
Result found: flight 136708 (fail), for first failure
Repro found: flight 136709 (pass), for last pass
Repro found: flight 136710 (fail), for first failure
Repro found: flight 136711 (pass), for last pass
Repro found: flight 136714 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 03957f58db8942d61f4889b6924e39d3b27a9e43
Bug not present: 57d87ee3a5d10cdba972eec3a54cd971fec1b8d2
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/136714/
commit 03957f58db8942d61f4889b6924e39d3b27a9e43
Author: Julien Grall <julien.grall@arm.com>
Date: Tue May 14 13:24:38 2019 +0100
xen/const: Extend the existing macro BIT to take a suffix in parameter
Arm currently provides two macro BIT and BIT_ULL that are only usable
in C and return respectively unsigned long and unsigned long long.
Extending the macros to deal with assembly would be a nice benefits as
it could replace the common pattern to define fields (AC(1, sfx) << X)
easier to read.
Rather than extending the two macros, it was decided to drop BIT_ULL()
and extend the macro BIT() to take a suffix (e.g U, UL, ULL) in
parameter. This would allow to use different suffix without having to
define new macros.
The new extend macro is now moved in include/xen/const.h so it can be
used by anyone in Xen and also avoid to include bitops.h in assembly
code.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Revision graph left in /home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.{dot,ps,png,html,svg}.
----------------------------------------
136714: tolerable ALL FAIL
flight 136714 xen-unstable-smoke real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/136714/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
build-arm64-xsm 6 xen-build fail baseline untested
jobs:
build-arm64-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] 7+ messages in thread
end of thread, other threads:[~2020-02-12 16:14 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-26 4:16 [Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm osstest service owner
-- strict thread matches above, loose matches on Subject: below --
2020-02-12 16:13 osstest service owner
2020-01-24 0:21 osstest service owner
2020-01-14 17:18 osstest service owner
2019-12-20 7:08 osstest service owner
2019-09-20 19:42 osstest service owner
2019-05-21 18:46 osstest service owner
2019-05-21 18:46 ` [Xen-devel] " 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).