|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable-smoke test] 141349: regressions - FAIL
flight 141349 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141349/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass version targeted for testing: xen cd93953538aac6026a8012d14a63b320eadd0c98 baseline version: xen 1014f47c7a808e025b8920ab80bfe73a2888b3e5 Last test of basis 141253 2019-09-12 17:00:43 Z 3 days Failing since 141255 2019-09-12 21:01:22 Z 3 days 22 attempts Testing same since 141274 2019-09-13 12:01:53 Z 2 days 18 attempts ------------------------------------------------------------ People who touched revisions under test: Chao Gao <chao.gao@xxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Juergen Gross <jgross@xxxxxxxx> Julien Grall <julien.grall@xxxxxxx> Paul Durrant <paul.durrant@xxxxxxxxxx> Stefano Stabellini <sstabellini@xxxxxxxxxx> 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 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 Not pushing. ------------------------------------------------------------ commit cd93953538aac6026a8012d14a63b320eadd0c98 Author: Chao Gao <chao.gao@xxxxxxxxx> Date: Fri Sep 13 12:31:34 2019 +0200 microcode: pass a patch pointer to apply_microcode() apply_microcode()'s always loading the cached ucode patch forces a patch to be stored before being loaded. Make apply_microcode() accept a patch pointer to remove the limitation so that a patch can be stored after a successful loading. Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 86f6706e4f4aa898bd6ffe8f1713fd175cc2c7c9 Author: Chao Gao <chao.gao@xxxxxxxxx> Date: Fri Sep 13 12:31:01 2019 +0200 microcode/amd: call svm_host_osvw_init() in common code Introduce a vendor hook, .end_update_percpu, for svm_host_osvw_init(). The hook function is called on each cpu after loading an update. It is a preparation for spliting out apply_microcode() from cpu_request_microcode(). Note that svm_host_osvm_init() should be called regardless of the result of loading an update. Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 41df5999f1f611ccbaedb15f5a4dbd1c1a634173 Author: Chao Gao <chao.gao@xxxxxxxxx> Date: Fri Sep 13 12:30:12 2019 +0200 microcode: remove pointless 'cpu' parameter Some callbacks in microcode_ops or related functions take a cpu id parameter. But at current call sites, the cpu id parameter is always equal to current cpu id. Some of them even use an assertion to guarantee this. Remove this redundent 'cpu' parameter. Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 81cc0f3931435374077184665148335fca245849 Author: Chao Gao <chao.gao@xxxxxxxxx> Date: Fri Sep 13 12:28:44 2019 +0200 microcode: remove struct ucode_cpu_info Remove the per-cpu cache field in struct ucode_cpu_info since it has been replaced by a global cache. It would leads to only one field remaining in ucode_cpu_info. Then, this struct is removed and the remaining field (cpu signature) is stored in per-cpu area. The cpu status notifier is also removed. It was used to free the "mc" field to avoid memory leak. Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 831f16274942ce70fbb50c438589f82c7d631257 Author: Chao Gao <chao.gao@xxxxxxxxx> Date: Fri Sep 13 12:28:13 2019 +0200 microcode: clean up microcode_resume_cpu Previously, a per-cpu ucode cache is maintained. Then each CPU had one per-cpu update cache and there might be multiple versions of microcode. Thus microcode_resume_cpu tried best to update microcode by loading every update cache until a successful load. But now the cache struct is simplified a lot and only a single ucode is cached. a single invocation of ->apply_microcode() would load the cache and make microcode updated. Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 9da23943ccd557ddb6c34e96e3bc078a51ad8205 Author: Chao Gao <chao.gao@xxxxxxxxx> Date: Fri Sep 13 12:27:42 2019 +0200 microcode: introduce a global cache of ucode patch to replace the current per-cpu cache 'uci->mc'. With the assumption that all CPUs in the system have the same signature (family, model, stepping and 'pf'), one microcode update matches with one cpu should match with others. Having differing microcode revisions on cpus would cause system unstable and should be avoided. Hence, caching one microcode update is good enough for all cases. Introduce a global variable, microcode_cache, to store the newest matching microcode update. Whenever we get a new valid microcode update, its revision id is compared against that of the microcode update to determine whether the "microcode_cache" needs to be replaced. And this global cache is loaded to cpu in apply_microcode(). All operations on the cache is protected by 'microcode_mutex'. Note that I deliberately avoid touching the old per-cpu cache ('uci->mc') as I am going to remove it completely in the following patches. We copy everything to create the new cache blob to avoid reusing some buffers previously allocated for the old per-cpu cache. It is not so efficient, but it is already corrected by a patch later in this series. Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> commit 68f94ef8e57cea82680b7bda2e03caabcba6d0a6 Author: Chao Gao <chao.gao@xxxxxxxxx> Date: Fri Sep 13 12:26:51 2019 +0200 microcode/amd: distinguish old and mismatched ucode in microcode_fits() Sometimes, an ucode with a level lower than or equal to current CPU's patch level is useful. For example, to work around a broken bios which only loads ucode for BSP, when BSP parses an ucode blob during bootup, it is better to save an ucode with lower or equal level for APs No functional change is made in this patch. But following patch would handle "old ucode" and "mismatched ucode" separately. Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 1097aeb27afedd7fd713ea2d22a7f44c6429ccbc Author: Chao Gao <chao.gao@xxxxxxxxx> Date: Fri Sep 13 12:26:16 2019 +0200 microcode/intel: extend microcode_update_match() to a more generic function. So that it can be used alone to check an update against the CPU signature and current update revision. Note that enum microcode_match_result will be used in common code (aka microcode.c), it has been placed in the common header. And constifying the parameter of microcode_sanity_check() such that it can be called by microcode_update_match(). Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 78481f525876a6f753866715abaf834f9a4cbc1a Author: Paul Durrant <paul.durrant@xxxxxxxxxx> Date: Fri Sep 13 12:21:47 2019 +0200 public/xen.h: update the comment explaining 'Wallclock time' Since commit 0629adfd80e "Actually set a HVM domain's time offset when it sets the RTC", the comment in the public header has been misleading, since it claims that wallclock time is only updated by control software. Moreover, the comments stating that wc_sec and wc_nsec are seconds and nanoseconds (respectively) in UTC since the Unix epoch are bogus. Their values are adjusted by the domain's time_offset_seconds value, which is updated by a guest write to the emulated RTC and hence the wallclock timezone is under guest control. This patch attempts to bring the comment in line with reality whilst keeping it reasonably short. Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> commit f59866e2bc190f0838da1988e15722cac13403e5 Author: Paul Durrant <paul.durrant@xxxxxxxxxx> Date: Thu Sep 12 15:18:47 2019 +0100 Update my MAINTAINERS entries My Citrix email address will expire shortly. Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxx> commit 2bcddc4da118d528eb1fbf1637f91175ff9969ec Author: Juergen Gross <jgross@xxxxxxxx> Date: Fri Sep 13 08:15:05 2019 +0200 debugtrace: fix Arm build Add missing #includes. Signed-off-by: Juergen Gross <jgross@xxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> commit 6e3e771203781ba6483636a732b2644fd6cab081 Author: Julien Grall <julien.grall@xxxxxxx> Date: Wed Sep 11 16:31:34 2019 +0100 xen/arm: setup: Relocate the Device-Tree later on in the boot At the moment, the Device-Tree is relocated into xenheap while setting up the memory subsystem. This is actually not necessary because the early mapping is still present and we don't require the virtual address to be stable until unflatting the Device-Tree. So the relocation can safely be moved after the memory subsystem is fully setup. This has the nice advantage to make the relocation common and let the xenheap allocator decides where to put it. Lastly, the device-tree is not going to be used for ACPI system. So there are no need to relocate it and can just be discarded. Signed-off-by: Julien Grall <julien.grall@xxxxxxx> Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx> Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> commit 0a19673affbc9177ea5f758ba245c70dd1a45a90 Author: Julien Grall <julien.grall@xxxxxxx> Date: Wed Sep 11 16:19:42 2019 +0100 xen/arm: bootfd: Fix indentation in process_multiboot_node() One line in process_multiboot_node() is using hard tab rather than soft tab. So fix it! Signed-off-by: Julien Grall <julien.grall@xxxxxxx> Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx> Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |