* [Xen-devel] [xen-unstable-smoke test] 145806: tolerable all pass
@ 2020-01-08 17:22 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2020-01-08 17:22 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 145806 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145806/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
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-amd64-amd64-libvirt 13 migrate-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 3840e98f3e72b7b92071089a042cd7cf5be72732
baseline version:
xen 4dde27b6e0a0b0dcb8fdfc7580fbd9c976aa103f
Last test of basis 145752 2020-01-07 18:00:34 Z 0 days
Testing same since 145806 2020-01-08 15:00:58 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
George Dunlap <george.dunlap@citrix.com>
Jan Beulich <jbeulich@suse.com>
Juergen Gross <jgross@suse.com>
Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Wei Liu <wl@xen.org>
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
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
Pushing revision :
ssh: Could not resolve hostname xenbits.xen.org: Temporary failure in name resolution
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
------------------------------------------------------------
commit 3840e98f3e72b7b92071089a042cd7cf5be72732
Author: Jan Beulich <jbeulich@suse.com>
Date: Wed Jan 8 15:04:36 2020 +0100
libxl: don't needlessly report "highmem" in use
Due to the unconditional updating of dom->highmem_end in
libxl__domain_device_construct_rdm() I've observed on a 2Gb HVM guest
with a passed through device (without overly large BARs, and with no RDM
ranges at all)
(d2) RAM in high memory; setting high_mem resource base to 100000000
...
(d2) E820 table:
(d2) [00]: 00000000:00000000 - 00000000:000a0000: RAM
(d2) HOLE: 00000000:000a0000 - 00000000:000d0000
(d2) [01]: 00000000:000d0000 - 00000000:00100000: RESERVED
(d2) [02]: 00000000:00100000 - 00000000:7f800000: RAM
(d2) HOLE: 00000000:7f800000 - 00000000:fc000000
(d2) [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
(d2) [04]: 00000001:00000000 - 00000001:00000000: RAM
both of which aren't really appropriate in this case. Arrange for this
to not happen.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wl@xen.org>
commit fe4df51ff776c8e543879ed552ace34d217e048d
Author: Jan Beulich <jbeulich@suse.com>
Date: Wed Jan 8 15:03:58 2020 +0100
x86/mm: re-order a few conditionals
is_{hvm,pv}_*() can be expensive now, so where possible evaluate cheaper
conditions first.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit a4cde0266d4287650ec62d8f850e4f84359e5e4f
Author: Jan Beulich <jbeulich@suse.com>
Date: Wed Jan 8 15:03:19 2020 +0100
x86/mm: rename and tidy create_pae_xen_mappings()
After dad74b0f9e ("i386: fix handling of Xen entries in final L2 page
table") and the removal of 32-bit support the function doesn't modify
state anymore, and hence its name has been misleading. Change its name,
constify parameters and a local variable, and make it return bool.
Also drop the call to it from mod_l3_entry(): The function explicitly
disallows 32-bit domains to modify slot 3. This way we also won't
re-check slot 3 when a slot other than slot 3 changes. Doing so has
needlessly disallowed making some L2 table recursively link back to an
L2 used in some L3's 3rd slot, as we check for the type ref count to be
1. (Note that allowing dynamic changes of L3 entries in the way we do is
bogus anyway, as that's not how L3s behave in the native and EPT cases:
They get re-evaluated only upon CR3 reloads. NPT is different in this
regard.)
As a result of this we no longer need to play games to get at the start
of the L3 table.
Additionally move the single remaining call site, allowing to drop one
is_pv_32bit_domain() invocation and a _PAGE_PRESENT check (in the
function itself) as well as to exit the loop early (remaining entries
have all been set to empty just ahead of this loop).
Further move a BUG_ON() such that in the common case its condition
wouldn't need evaluating.
Finally, since we're at it, move init_xen_pae_l2_slots() next to the
renamed function, as they really belong together (in fact
init_xen_pae_l2_slots() was [indirectly] broken out of this function).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 8931fc9a1d7c7f4afd339b314fe7881fc06e2f5d
Author: Jan Beulich <jbeulich@suse.com>
Date: Wed Jan 8 15:02:26 2020 +0100
x86/mm: mod_l<N>_entry() have no need to use __copy_from_user()
mod_l1_entry()'s need to do so went away with commit 2d0557c5cb ("x86:
Fold page_info lock into type_info"), and the other three never had such
a need, at least going back as far as 3.2.0. Replace the uses by
l<N>e_read_atomic().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit d7f3c76317108ee9989f00545d394fa495fba752
Author: Juergen Gross <jgross@suse.com>
Date: Wed Jan 8 14:59:25 2020 +0100
sched: fix resuming from S3 with smt=0
When resuming from S3 and smt=0 or maxcpus= are specified we must not
do anything in cpu_schedule_callback(). This is not true today for
taking down a cpu during resume.
If anything goes wrong during resume all the scheduler related error
handling is in cpupool.c, so we can just bail out early from
cpu_schedule_callback() when suspending or resuming.
This fixes commit 0763cd2687897b55e7 ("xen/sched: don't disable
scheduler on cpus during suspend").
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-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] only message in thread
only message in thread, other threads:[~2020-01-08 17:23 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-08 17:22 [Xen-devel] [xen-unstable-smoke test] 145806: tolerable all pass 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.