* [xen-unstable-smoke test] 165668: regressions - FAIL
@ 2021-10-19 13:42 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2021-10-19 13:42 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 165668 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165668/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 11 leak-check/basis(11) fail REGR. vs. 165635
test-amd64-amd64-libvirt 11 leak-check/basis(11) fail REGR. vs. 165635
test-arm64-arm64-xl-xsm 11 leak-check/basis(11) fail REGR. vs. 165635
test-armhf-armhf-xl 11 leak-check/basis(11) fail REGR. vs. 165635
version targeted for testing:
xen b7635526acffbe4ad8ad16fd92812c57742e54c2
baseline version:
xen c11b8d25fbe9c0155e91409594ea6701008409ed
Last test of basis 165635 2021-10-18 13:00:26 Z 1 days
Failing since 165638 2021-10-18 16:01:36 Z 0 days 5 attempts
Testing same since 165668 2021-10-19 10:00:25 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Ian Jackson <iwj@xenproject.org>
Jan Beulich <jbeulich@suse.com>
Juergen Gross <jgross@suse.com>
Roger Pau Monné <roger.pau@citrix.com>
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl fail
test-arm64-arm64-xl-xsm fail
test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail
test-amd64-amd64-libvirt 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
Not pushing.
------------------------------------------------------------
commit b7635526acffbe4ad8ad16fd92812c57742e54c2
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Oct 19 10:08:30 2021 +0200
x86/paging: restrict physical address width reported to guests
Modern hardware may report more than 48 bits of physical address width.
For paging-external guests our P2M implementation does not cope with
larger values. Telling the guest of more available bits means misleading
it into perhaps trying to actually put some page there (like was e.g.
intermediately done in OVMF for the shared info page).
While there also convert the PV check to a paging-external one (which in
our current code base are synonyms of one another anyway).
Fixes: 5dbd60e16a1f ("x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
commit 525eac931794434593c39a1d1cd739ad8b326e27
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Oct 19 10:07:42 2021 +0200
x86/PV: replace assertions in '0' debug key stack dumping
While it was me to add them, I'm afraid I don't see justification for
the assertions: A vCPU may very well have got preempted while in user
mode. Limit compat guest user mode stack dumps to the containing page
(like is done when using do_page_walk()), and suppress user mode stack
dumping altogether for 64-bit domains.
Fixes: cc0de53a903c ("x86: improve output resulting from sending '0' over serial")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
commit 4843546fef5e024d5754f722fd01a8dfb482ac7d
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Oct 19 10:07:00 2021 +0200
x86/PV: make '0' debug key dump Dom0's stacks again
The conversion to __get_guest() failed to account for the fact that for
remote vCPU-s dumping gets done through a pointer obtained from
map_domain_page(): __get_guest() arranges for (apparent) accesses to
hypervisor space to cause #GP(0).
Fixes: 6a1d72d3739e ('x86: split __{get,put}_user() into "guest" and "unsafe" variants')
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
commit 5e97b97bc254b0ee23f701a4d5a317853136d288
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Oct 19 10:05:10 2021 +0200
x86/altp2m: don't consider "active" when enabling failed
We should not rely on guests to not use altp2m after reporting failure
of HVMOP_altp2m_set_domain_state to them. Set "active" back to false in
this case.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tamas K Lengyel <tamas@tklengyel.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
commit d6e38eea2d806c53d976603717aebf6e5de30a1e
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Oct 19 10:04:13 2021 +0200
x86/AMD: make HT range dynamic for Fam17 and up
At the time of d838ac2539cf ("x86: don't allow Dom0 access to the HT
address range") documentation correctly stated that the range was
completely fixed. For Fam17 and newer, it lives at the top of physical
address space, though.
To correctly determine the top of physical address space, we need to
account for their physical address reduction, hence the calculation of
paddr_bits also gets adjusted.
While for paddr_bits < 40 the HT range is completely hidden, there's no
need to suppress the range insertion in that case: It'll just have no
real meaning.
Reported-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
commit a8cddbac5051020bb4a59a7f0ea27500c51063fb
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Oct 19 10:02:39 2021 +0200
x86emul: de-duplicate scatters to the same linear address
The SDM specifically allows for earlier writes to fully overlapping
ranges to be dropped. If a guest did so, hvmemul_phys_mmio_access()
would crash it if varying data was written to the same address. Detect
overlaps early, as doing so in hvmemul_{linear,phys}_mmio_access() would
be quite a bit more difficult. To maintain proper faulting behavior,
instead of dropping earlier write instances of fully overlapping slots
altogether, write the data of the final of these slots multiple times.
(We also can't pull ahead the [single] write of the data of the last of
the slots, clearing all involved slots' op_mask bits together, as this
would yield incorrect results if there were intervening partially
overlapping ones.)
Note that due to cache slot use being linear address based, there's no
similar issue with multiple writes to the same physical address (mapped
through different linear addresses).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
commit 3ae80dea4601764818d1e5b84bd1e4479c0d4790
Author: Juergen Gross <jgross@suse.com>
Date: Fri Sep 10 07:55:17 2021 +0200
stubdom: disable building pv-grub
The stubdom based pv-grub is using a very outdated version of grub
(0.97) and should not be used any longer. Mainline grub has support for
PV guests for a long time now, so that should be used as a boot loader
of a PV domain.
So disable building pv-grub per default. In case someone really wants
to continue using it he/she can still use a pv-grub binary from an older
Xen version or manually enable building it via:
configure --enable-pv-grub
[ This was already disabled in osstest by 8dee6e333622
"make-flight: Drop pvgrub (pvgrub1) tests" -iwj ]
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Ian Jackson <iwj@xenproject.org>
Release-Acked-by: Ian Jackson <iwj@xenproject.org>
commit 9cfeb83cbe23a873de512211d7ecd989348b9df0
Author: Juergen Gross <jgross@suse.com>
Date: Tue Oct 12 15:41:48 2021 +0200
tools/xenstore: set open file descriptor limit for xenstored
Add a configuration item for the maximum number of open file
descriptors xenstored should be allowed to have.
The default should be "unlimited" in order not to restrict xenstored
in the number of domains it can support, but unfortunately the kernel
is normally limiting the maximum value via /proc/sys/fs/nr_open [1],
[2]. So check that file to exist and if it does, limit the maximum
value to the one specified by /proc/sys/fs/nr_open.
As an aid for the admin configuring the value add a comment specifying
the common needs of xenstored for the different domain types.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=60fd760fb9ff7034360bab7137c917c0330628c2
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c2d64fb6cae9aae480f6a46cfe79f8d7d48b59f
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Ian Jackson <iwj@xenproject.org>
Release-Acked-by: Ian Jackson <iwj@xenproject.org>
commit f282182af32939107d47943aba242d3189ec6f90
Author: Juergen Gross <jgross@suse.com>
Date: Tue Oct 12 15:41:47 2021 +0200
tools/xenstore: set oom score for xenstore daemon on Linux
Xenstored is absolutely mandatory for a Xen host and it can't be
restarted, so being killed by OOM-killer in case of memory shortage is
to be avoided.
Set /proc/$pid/oom_score_adj (if available) per default to -500 (this
translates to 50% of dom0 memory size) in order to allow xenstored to
use large amounts of memory without being killed.
The percentage of dom0 memory above which the oom killer is allowed to
kill xenstored can be set via XENSTORED_OOM_MEM_THRESHOLD in
xencommons.
Make sure the pid file isn't a left-over from a previous run delete it
before starting xenstored.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Ian Jackson <iwj@xenproject.org>
Release-Acked-by: Ian Jackson <iwj@xenproject.org>
(qemu changes not included)
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2021-10-19 13:43 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-10-19 13:42 [xen-unstable-smoke test] 165668: 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.