* [xen-unstable-smoke test] 128019: regressions - FAIL
@ 2018-09-24 20:34 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2018-09-24 20:34 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 128019 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128019/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 127928
Tests which did not succeed, but are not blocking:
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 1bd9cc34e152addeacbbf44898125c7be00e7677
baseline version:
xen 940185b2f6f343251c2b83bd96e599398cea51ec
Last test of basis 127928 2018-09-22 10:00:53 Z 2 days
Failing since 128013 2018-09-24 14:00:44 Z 0 days 2 attempts
Testing same since 128019 2018-09-24 18:00:28 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Amit Singh Tomar <amittomer25@gmail.com>
Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien.grall@arm.com>
Tamas K Lengyel <tamas@tklengyel.com>
Wei Liu <wei.liu2@citrix.com>
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 fail
test-amd64-amd64-xl-qemuu-debianhvm-i386 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 1bd9cc34e152addeacbbf44898125c7be00e7677
Author: Wei Liu <wei.liu2@citrix.com>
Date: Fri Sep 21 16:54:52 2018 +0100
x86: expose CONFIG_HVM
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 026eac063bf756e9f5aa9afa1e4cb6b50dcf2a5b
Author: Wei Liu <wei.liu2@citrix.com>
Date: Fri Sep 21 16:54:51 2018 +0100
x86/mm: put HVM only code under CONFIG_HVM
Going through the code, HAP, EPT, PoD and ALTP2M depend on HVM code.
Put these components under CONFIG_HVM. This further requires putting
one of the vm event under CONFIG_HVM.
Altp2m requires a bit more attention because its code is embedded in
generic x86 p2m code.
Also make hap_enabled evaluate to false when !CONFIG_HVM. Make sure it
evaluate its parameter to avoid unused variable warnings in its users.
Also sort items in Makefile while at it.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
commit 9629b62005fa88424a4f48102848c4524d0341e3
Author: Wei Liu <wei.liu2@citrix.com>
Date: Fri Sep 21 16:54:50 2018 +0100
x86/mm: put nested p2m code under CONFIG_HVM
These functions are only useful for nested hvm, which isn't enabled
when CONFIG_HVM is false.
Enclose relevant code and fields in CONFIG_HVM.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
commit 72a901d7a04305f24f7b1e723e6cf18c744cff95
Author: Wei Liu <wei.liu2@citrix.com>
Date: Fri Sep 21 16:54:49 2018 +0100
x86/p2m/pod: make it build with !CONFIG_HVM
Populate-on-demand is HVM only.
Provide a bunch of stubs for common p2m code and guard one invocation
of guest_physmap_mark_populate_on_demand with is_hvm_domain.
Put relevant fields in p2m_domain and code which touches those fields
under CONFIG_HVM.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
commit 39d42a2daee3d0b4c12ce7391faf4763eff09e6b
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Feb 21 17:54:13 2018 +0000
x86: Clean up the Xen MSR infrastructure
Rename them to guest_{rd,wr}msr_xen() for consistency, and because the _regs
suffix isn't very appropriate.
Update them to take a vcpu pointer rather than presuming that they act on
current, and switch to using X86EMUL_* return values.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
commit 229b94878717e22c0f228625bbcddd53f7d8654d
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Sep 20 17:33:59 2017 +0000
x86/viridan: Clean up Viridian MSR infrastructure
Rename the functions to guest_{rd,wr}msr_viridian() for consistency, and
because the _regs() suffix isn't very appropriate.
Update them to take a vcpu pointer rather than presuming that they act on
current, which is safe for all implemented operations, and switch their return
ABI to use X86EMUL_*.
The default cases no longer need to deal with MSRs out of the Viridian range,
but drop the printks to debug builds only and identify the value attempting to
be written.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
commit bd7099a674819c0709bd058793adea2e76b42a6b
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Sep 20 18:33:59 2017 +0100
x86/msr: Dispatch Xen and Viridian MSRs from guest_{wr,rd}msr()
Despite the complicated diff in {svm,vmx}_msr_write_intercept(), it is just
the 0 case losing one level of indentation, as part of removing the call to
wrmsr_hypervisor_regs().
The case blocks in guest_{wr,rd}msr() use raw numbers, partly for consistency
with the CPUID side of things, but mainly because this is clearer code to
follow. In particular, the Xen block may overlap with the Viridian block if
Viridian is not enabled for the domain, and trying to express this with named
literals caused more confusion that it solved.
Future changes with clean up the individual APIs, including allowing these
MSRs to be usable for vcpus other than current (no callers exist with v !=
current).
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit cd8015b634b005a3911bd6025351cd854d63a82a
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon Sep 24 14:00:02 2018 +0100
ARM/dom0: Avoid using a variable length array in make_memory_node()
The reg[] array can have a maximum size of 8 in practice, so use the worst
case calculation rather than making it variable length.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
commit 17bd254a508f4174fe0d56a9f1b9892b7649b4b9
Author: Amit Singh Tomar <amittomer25@gmail.com>
Date: Tue Sep 11 22:18:06 2018 +0530
xen:arm: Populate arm64 image header
This patch adds image size and flags to XEN image header. It uses
those fields according to the updated Linux kernel image definition.
With this patch bootloader can now place XEN image anywhere in system
RAM at 2MB aligned address without to worry about relocation.
For instance, it fixes the XEN boot on Amlogic SoC where bootloader(U-BOOT)
always relocates the XEN image to an address range reserved for firmware data.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
Reviewed-by: Andre Pryzwara <andre.przywara@arm.com>
Acked-by: Julien Grall <julien.grall@arm.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:[~2018-09-24 20:34 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-24 20:34 [xen-unstable-smoke test] 128019: 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.