* [xen-unstable-smoke test] 136280: regressions - FAIL
@ 2019-05-15 7:50 osstest service owner
2019-05-15 7:50 ` [Xen-devel] " osstest service owner
0 siblings, 1 reply; 2+ messages in thread
From: osstest service owner @ 2019-05-15 7:50 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 136280 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136280/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-build fail REGR. vs. 136179
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
build-amd64-libvirt 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
version targeted for testing:
xen 3c04c258ab40405a74e194d9889a4cbc7abe94b4
baseline version:
xen 99bb45e684283b3bc621dbc99b1b93c856b4dd1c
Last test of basis 136179 2019-05-13 16:02:31 Z 1 days
Failing since 136227 2019-05-14 15:01:02 Z 0 days 5 attempts
Testing same since 136241 2019-05-14 19:10:38 Z 0 days 4 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien.grall@arm.com>
jobs:
build-arm64-xsm pass
build-amd64 fail
build-armhf pass
build-amd64-libvirt blocked
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked
test-amd64-amd64-libvirt blocked
------------------------------------------------------------
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
Not pushing.
------------------------------------------------------------
commit 3c04c258ab40405a74e194d9889a4cbc7abe94b4
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Dec 12 19:22:15 2018 +0000
x86/spec-ctrl: Introduce options to control VERW flushing
The Microarchitectural Data Sampling vulnerability is split into categories
with subtly different properties:
MLPDS - Microarchitectural Load Port Data Sampling
MSBDS - Microarchitectural Store Buffer Data Sampling
MFBDS - Microarchitectural Fill Buffer Data Sampling
MDSUM - Microarchitectural Data Sampling Uncacheable Memory
MDSUM is a special case of the other three, and isn't distinguished further.
These issues pertain to three microarchitectural buffers. The Load Ports, the
Store Buffers and the Fill Buffers. Each of these structures are flushed by
the new enhanced VERW functionality, but the conditions under which flushing
is necessary vary.
For this concise overview of the issues and default logic, the abbreviations
SP (Store Port), FB (Fill Buffer), LP (Load Port) and HT (Hyperthreading) are
used for brevity:
* Vulnerable hardware is divided into two categories - parts which suffer
from SP only, and parts with any other combination of vulnerabilities.
* SP only has an HT interaction when the thread goes idle, due to the static
partitioning of resources. LP and FB have HT interactions at all points,
due to the competitive sharing of resources. All issues potentially leak
data across the return-to-guest transition.
* The microcode which implements VERW flushing also extends MSR_FLUSH_CMD, so
we don't need to do both on the HVM return-to-guest path. However, some
parts are not vulnerable to L1TF (therefore have no MSR_FLUSH_CMD), but are
vulnerable to MDS, so do require VERW on the HVM path.
Note that we deliberately support mds=1 even without MD_CLEAR in case the
microcode has been updated but the feature bit not exposed.
This is part of XSA-297, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 548a932ac786d6bf3584e4b54f2ab993e1117710
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Dec 12 19:22:15 2018 +0000
x86/spec-ctrl: Infrastructure to use VERW to flush pipeline buffers
Three synthetic features are introduced, as we need individual control of
each, depending on circumstances. A later change will enable them at
appropriate points.
The verw_sel field doesn't strictly need to live in struct cpu_info. It lives
there because there is a convenient hole it can fill, and it reduces the
complexity of the SPEC_CTRL_EXIT_TO_{PV,HVM} assembly by avoiding the need for
any temporary stack maintenance.
This is part of XSA-297, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit d4f6116c080dc013cd1204c4d8ceb95e5f278689
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Sep 12 14:36:00 2018 +0100
x86/spec-ctrl: CPUID/MSR definitions for Microarchitectural Data Sampling
The MD_CLEAR feature can be automatically offered to guests. No
infrastructure is needed in Xen to support the guest making use of it.
This is part of XSA-297, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 9b62eba6c429c327e1507816bef403ccc87357ae
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Sep 12 14:36:00 2018 +0100
x86/spec-ctrl: Misc non-functional cleanup
* Identify BTI in the spec_ctrl_{enter,exit}_idle() comments, as other
mitigations will shortly appear.
* Use alternative_input() and cover the lack of memory cobber with a further
barrier.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 14e122fcc45d8a86e27be9663cbd7bcea1602b25
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue May 14 16:22:17 2019 +0200
IOMMU: avoid NULL deref in iommu_lookup_page()
Luckily the function currently has no callers - it would have called
through NULL for both Arm and x86/AMD.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
commit 05fe88fef20bafb2b62190b08f28211a1c4a1b12
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue May 14 16:21:33 2019 +0200
x86/mm: subsume set_gpfn_from_mfn() into guest_physmap_add_page()
The two callers in common/memory.c currently call set_gpfn_from_mfn()
themselves, so moving the call into guest_physmap_add_page() helps
tidy their code.
The two callers in common/grant_table.c fail to make that call alongside
the one to guest_physmap_add_page(), so will actually get fixed by the
change.
Other (x86) callers are HVM only and are hence unaffected by a change
to the function's !paging_mode_translate() part.
Sadly this isn't enough yet to drop Arm's dummy macro, as there's one
more use in page_alloc.c.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
commit cf7de5d9543bba1076fe8ede57b0d314394c943a
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue May 14 16:20:06 2019 +0200
x86/mm: make guest_physmap_add_entry() HVM-only
Lift its !paging_mode_translate() part into guest_physmap_add_page()
(which is what common code calls), eliminating the dummy use of a
(HVM-only really) P2M type in the PV case.
Suggested-by: George Dunlap <George.Dunlap@eu.citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
commit b81813dfb36fde9bd47c2e1b806e368cb9d6cbdb
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue May 14 16:18:58 2019 +0200
x86/mm: short-circuit HVM-only mode flags when !HVM
#define-ing them to zero allows better code generation in this case,
and paves the way for more DCE, allowing to leave certain functions just
declared, but not defined.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Xen-devel] [xen-unstable-smoke test] 136280: regressions - FAIL
2019-05-15 7:50 [xen-unstable-smoke test] 136280: regressions - FAIL osstest service owner
@ 2019-05-15 7:50 ` osstest service owner
0 siblings, 0 replies; 2+ messages in thread
From: osstest service owner @ 2019-05-15 7:50 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 136280 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136280/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-build fail REGR. vs. 136179
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
build-amd64-libvirt 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
version targeted for testing:
xen 3c04c258ab40405a74e194d9889a4cbc7abe94b4
baseline version:
xen 99bb45e684283b3bc621dbc99b1b93c856b4dd1c
Last test of basis 136179 2019-05-13 16:02:31 Z 1 days
Failing since 136227 2019-05-14 15:01:02 Z 0 days 5 attempts
Testing same since 136241 2019-05-14 19:10:38 Z 0 days 4 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien.grall@arm.com>
jobs:
build-arm64-xsm pass
build-amd64 fail
build-armhf pass
build-amd64-libvirt blocked
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked
test-amd64-amd64-libvirt blocked
------------------------------------------------------------
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
Not pushing.
------------------------------------------------------------
commit 3c04c258ab40405a74e194d9889a4cbc7abe94b4
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Dec 12 19:22:15 2018 +0000
x86/spec-ctrl: Introduce options to control VERW flushing
The Microarchitectural Data Sampling vulnerability is split into categories
with subtly different properties:
MLPDS - Microarchitectural Load Port Data Sampling
MSBDS - Microarchitectural Store Buffer Data Sampling
MFBDS - Microarchitectural Fill Buffer Data Sampling
MDSUM - Microarchitectural Data Sampling Uncacheable Memory
MDSUM is a special case of the other three, and isn't distinguished further.
These issues pertain to three microarchitectural buffers. The Load Ports, the
Store Buffers and the Fill Buffers. Each of these structures are flushed by
the new enhanced VERW functionality, but the conditions under which flushing
is necessary vary.
For this concise overview of the issues and default logic, the abbreviations
SP (Store Port), FB (Fill Buffer), LP (Load Port) and HT (Hyperthreading) are
used for brevity:
* Vulnerable hardware is divided into two categories - parts which suffer
from SP only, and parts with any other combination of vulnerabilities.
* SP only has an HT interaction when the thread goes idle, due to the static
partitioning of resources. LP and FB have HT interactions at all points,
due to the competitive sharing of resources. All issues potentially leak
data across the return-to-guest transition.
* The microcode which implements VERW flushing also extends MSR_FLUSH_CMD, so
we don't need to do both on the HVM return-to-guest path. However, some
parts are not vulnerable to L1TF (therefore have no MSR_FLUSH_CMD), but are
vulnerable to MDS, so do require VERW on the HVM path.
Note that we deliberately support mds=1 even without MD_CLEAR in case the
microcode has been updated but the feature bit not exposed.
This is part of XSA-297, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 548a932ac786d6bf3584e4b54f2ab993e1117710
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Dec 12 19:22:15 2018 +0000
x86/spec-ctrl: Infrastructure to use VERW to flush pipeline buffers
Three synthetic features are introduced, as we need individual control of
each, depending on circumstances. A later change will enable them at
appropriate points.
The verw_sel field doesn't strictly need to live in struct cpu_info. It lives
there because there is a convenient hole it can fill, and it reduces the
complexity of the SPEC_CTRL_EXIT_TO_{PV,HVM} assembly by avoiding the need for
any temporary stack maintenance.
This is part of XSA-297, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit d4f6116c080dc013cd1204c4d8ceb95e5f278689
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Sep 12 14:36:00 2018 +0100
x86/spec-ctrl: CPUID/MSR definitions for Microarchitectural Data Sampling
The MD_CLEAR feature can be automatically offered to guests. No
infrastructure is needed in Xen to support the guest making use of it.
This is part of XSA-297, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 9b62eba6c429c327e1507816bef403ccc87357ae
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Sep 12 14:36:00 2018 +0100
x86/spec-ctrl: Misc non-functional cleanup
* Identify BTI in the spec_ctrl_{enter,exit}_idle() comments, as other
mitigations will shortly appear.
* Use alternative_input() and cover the lack of memory cobber with a further
barrier.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 14e122fcc45d8a86e27be9663cbd7bcea1602b25
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue May 14 16:22:17 2019 +0200
IOMMU: avoid NULL deref in iommu_lookup_page()
Luckily the function currently has no callers - it would have called
through NULL for both Arm and x86/AMD.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
commit 05fe88fef20bafb2b62190b08f28211a1c4a1b12
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue May 14 16:21:33 2019 +0200
x86/mm: subsume set_gpfn_from_mfn() into guest_physmap_add_page()
The two callers in common/memory.c currently call set_gpfn_from_mfn()
themselves, so moving the call into guest_physmap_add_page() helps
tidy their code.
The two callers in common/grant_table.c fail to make that call alongside
the one to guest_physmap_add_page(), so will actually get fixed by the
change.
Other (x86) callers are HVM only and are hence unaffected by a change
to the function's !paging_mode_translate() part.
Sadly this isn't enough yet to drop Arm's dummy macro, as there's one
more use in page_alloc.c.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
commit cf7de5d9543bba1076fe8ede57b0d314394c943a
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue May 14 16:20:06 2019 +0200
x86/mm: make guest_physmap_add_entry() HVM-only
Lift its !paging_mode_translate() part into guest_physmap_add_page()
(which is what common code calls), eliminating the dummy use of a
(HVM-only really) P2M type in the PV case.
Suggested-by: George Dunlap <George.Dunlap@eu.citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
commit b81813dfb36fde9bd47c2e1b806e368cb9d6cbdb
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue May 14 16:18:58 2019 +0200
x86/mm: short-circuit HVM-only mode flags when !HVM
#define-ing them to zero allows better code generation in this case,
and paves the way for more DCE, allowing to leave certain functions just
declared, but not defined.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-05-15 7:51 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-15 7:50 [xen-unstable-smoke test] 136280: regressions - FAIL osstest service owner
2019-05-15 7:50 ` [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).