* [Xen-devel] [xen-unstable-smoke test] 146472: regressions - FAIL
@ 2020-01-24 14:16 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2020-01-24 14:16 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 146472 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146472/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-build fail REGR. vs. 146401
build-armhf 6 xen-build fail REGR. vs. 146401
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-armhf-armhf-xl 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
version targeted for testing:
xen 4345dff75a7838649c75a85aeb0e0de93853201d
baseline version:
xen 021cc01ecac111be3301ad33ff5cda4543ca8b92
Last test of basis 146401 2020-01-22 23:00:35 Z 1 days
Failing since 146420 2020-01-23 15:00:29 Z 0 days 10 attempts
Testing same since 146472 2020-01-24 12:01:10 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Alexandru Isaila <aisaila@bitdefender.com>
Alexandru Stefan ISAILA <aisaila@bitdefender.com>
Andrew Cooper <andrew.cooper3@citrix.com>
Eslam Elnikety <elnikety@amazon.com>
George Dunlap <george.dunlap@citrix.com>
Jan Beulich <jbeulich@suse.com>
Juergen Gross <jgross@suse.com>
Tamas K Lengyel <tamas.lengyel@intel.com>
Tamas K Lengyel <tamas@tklengyel.com>
jobs:
build-arm64-xsm fail
build-amd64 pass
build-armhf fail
build-amd64-libvirt pass
test-armhf-armhf-xl blocked
test-arm64-arm64-xl-xsm blocked
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-amd64-libvirt 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
Not pushing.
------------------------------------------------------------
commit 4345dff75a7838649c75a85aeb0e0de93853201d
Author: Eslam Elnikety <elnikety@amazon.com>
Date: Fri Jan 24 10:31:55 2020 +0100
x86/microcode: use const qualifier for microcode buffer
The buffer holding the microcode bits should be marked as const.
Signed-off-by: Eslam Elnikety <elnikety@amazon.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
commit e6eb81a028ba610de43bc966ced5d95bafe8911b
Author: Eslam Elnikety <elnikety@amazon.com>
Date: Fri Jan 24 10:31:21 2020 +0100
x86/microcode: avoid unnecessary xmalloc/memcpy of ucode data
When using `ucode=scan` and if a matching module is found, the microcode
payload is maintained in an xmalloc()'d region. This is unnecessary since
the bootmap would just do. Remove the xmalloc and xfree on the microcode
module scan path.
This commit also does away with the restriction on the microcode module
size limit. The concern that a large microcode module would consume too
much memory preventing guests launch is misplaced since this is all the
init path. While having such safeguards is valuable, this should apply
across the board for all early/late microcode loading. Having it just on
the `scan` path is confusing.
Looking forward, we are a bit closer (i.e., one xmalloc down) to pulling
the early microcode loading of the BSP a bit earlier in the early boot
process. This commit is the low hanging fruit. There is still a sizable
amount of work to get there as there are still a handful of xmalloc in
microcode_{amd,intel}.c.
First, there are xmallocs on the path of finding a matching microcode
update. Similar to the commit at hand, searching through the microcode
blob can be done on the already present buffer with no need to xmalloc
any further. Even better, do the filtering in microcode.c before
requesting the microcode update on all CPUs. The latter requires careful
restructuring and exposing the arch-specific logic for iterating over
patches and declaring a match.
Second, there are xmallocs for the microcode cache. Here, we would need
to ensure that the cache corresponding to the BSP gets xmalloc()'d and
populated after the fact.
Signed-off-by: Eslam Elnikety <elnikety@amazon.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
commit 6e73e7186dd73e8f638730135c298474f49de6a4
Author: Eslam Elnikety <elnikety@amazon.com>
Date: Fri Jan 24 10:30:54 2020 +0100
x86/microcode: improve documentation for ucode=
Specify applicability and the default value. Also state that, in case of
EFI, the microcode update blob specified in the EFI cfg takes precedence
over `ucode=scan`, if the latter is specified on Xen commend line.
No functional changes.
Signed-off-by: Eslam Elnikety <elnikety@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit e301cd9b0f05b0fe3f329a3bd3663618380a1310
Author: Juergen Gross <jgross@suse.com>
Date: Fri Jan 24 10:30:05 2020 +0100
sched: avoid cpumasks on stack in sched/core.c
There are still several instances of cpumask_t on the stack in
scheduling code. Avoid them as far as possible.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Dario Faggioli <dfaggioli@suse.com>
commit 67de3c5df067c6fcdc7c452752c1a14863d9b1c8
Author: Tamas K Lengyel <tamas.lengyel@intel.com>
Date: Fri Jan 24 10:28:56 2020 +0100
x86/mem_sharing: Skip xen heap pages in memshr nominate
Trying to share these would fail anyway, better to skip them early.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 72f8d45d69b84e2f5c76180fe046ecca1b2f99ea
Author: Tamas K Lengyel <tamas.lengyel@intel.com>
Date: Fri Jan 24 10:28:22 2020 +0100
x86/mem_sharing: enable mem_sharing on first memop
It is wasteful to require separate hypercalls to enable sharing on both the
parent and the client domain during VM forking. To speed things up we enable
sharing on the first memop in case it wasn't already enabled.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 96d4621f96bfdac97b85c3a278b4b51bcdd6f272
Author: Tamas K Lengyel <tamas.lengyel@intel.com>
Date: Fri Jan 24 10:27:35 2020 +0100
x86/mem_sharing: convert MEM_SHARING_DESTROY_GFN to a bool
MEM_SHARING_DESTROY_GFN is used on the 'flags' bitfield during unsharing.
However, the bitfield is not used for anything else, so just convert it to a
bool instead.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 1e470e160922f83e0f2f879229be9a6857bd54af
Author: Tamas K Lengyel <tamas.lengyel@intel.com>
Date: Fri Jan 24 10:25:47 2020 +0100
x86/mem_sharing: make add_to_physmap static and shorten name
It's not being called from outside mem_sharing.c
Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 5a9185c395527f4eebd788773c74e269f085bde4
Author: Tamas K Lengyel <tamas.lengyel@intel.com>
Date: Fri Jan 24 10:25:12 2020 +0100
x86/mem_sharing: use INVALID_MFN and p2m_is_shared in relinquish_shared_pages
While using _mfn(0) is of no consequence during teardown, INVALID_MFN is the
correct value that should be used.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 7f8d062d98c3b4ffbc7496b646bdacb44caac273
Author: Tamas K Lengyel <tamas.lengyel@intel.com>
Date: Fri Jan 24 10:24:18 2020 +0100
x86/mem_sharing: define mem_sharing_domain to hold some scattered variables
Create struct mem_sharing_domain under hvm_domain and move mem sharing
variables into it from p2m_domain and hvm_domain.
Expose the mem_sharing_enabled macro to be used consistently across Xen.
Remove some duplicate calls to mem_sharing_enabled in mem_sharing.c
Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
commit e6fcf0efe4464c8edde1406cf44b975e18f0fa72
Author: Tamas K Lengyel <tamas.lengyel@intel.com>
Date: Fri Jan 24 10:21:16 2020 +0100
x86/mem_sharing: don't try to unshare twice during page fault
The page was already tried to be unshared in get_gfn_type_access. If that
didn't work, then trying again is pointless. Don't try to send vm_event again
either, simply check if there is a ring or not.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
commit f268900fbc5b5339f76694e73f14e9261d4b8065
Author: Tamas K Lengyel <tamas.lengyel@intel.com>
Date: Fri Jan 24 10:19:42 2020 +0100
x86/mem_sharing: drop flags from mem_sharing_unshare_page
All callers pass 0 in.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
Reviewed-by: Wei Liu <wl@xen.org>
Acked-by: George Dunlap <george.dunlap@citrix.com>
commit 26bcc12f3af5f6a63807938c3c8200b49c9b9947
Author: Tamas K Lengyel <tamas.lengyel@intel.com>
Date: Fri Jan 24 10:18:10 2020 +0100
x86/mem_sharing: make get_two_gfns take locks conditionally
During VM forking the client lock will already be taken.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
commit 2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
Author: Alexandru Stefan ISAILA <aisaila@bitdefender.com>
Date: Fri Jan 17 13:31:33 2020 +0000
x86/mm: Make use of the default access param from xc_altp2m_create_view
At this moment the default_access param from xc_altp2m_create_view is
not used.
This patch assigns default_access to p2m->default_access at the time of
initializing a new altp2m view.
Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Reviewed-by: Petre Pircalabu <ppircalabu@bitdefender.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
commit b701adbee37befa58c7bdec80b65f93e033252e6
Author: Alexandru Stefan ISAILA <aisaila@bitdefender.com>
Date: Fri Jan 17 13:31:31 2020 +0000
x86/mm: Pull vendor-independent altp2m code out of p2m-ept.c and into p2m.c
No functional changes.
Requested-by: Jan Beulich <jbeulich@suse.com>
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>
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>
commit 5160dbd512523d865f7271af23636aa3f3536186
Author: Alexandru Stefan ISAILA <aisaila@bitdefender.com>
Date: Fri Jan 17 13:31:26 2020 +0000
x86/mm: Add array_index_nospec to guest provided index values
This patch aims to sanitize indexes, potentially guest provided
values, for altp2m_eptp[] and altp2m_p2m[] arrays.
Requested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.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] only message in thread
only message in thread, other threads:[~2020-01-24 14:17 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-24 14:16 [Xen-devel] [xen-unstable-smoke test] 146472: regressions - FAIL osstest service owner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.