[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable-smoke test] 120106: regressions - trouble: blocked/broken/pass
flight 120106 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120106/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf <job status> broken build-armhf 5 host-build-prep fail REGR. vs. 120098 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a 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 85688075ccc22c12bd0fca2a2c269199938e104c baseline version: xen cb671efbf1fae302c0ee5ebd6e23564e319babc8 Last test of basis 120098 2018-02-28 16:01:46 Z 0 days Testing same since 120102 2018-02-28 19:01:39 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxx> Kevin Tian <kevin.tian@xxxxxxxxx> Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> Tamas K Lengyel <tamas@xxxxxxxxxxxxx> jobs: build-arm64-xsm pass build-amd64 pass build-armhf broken build-amd64-libvirt pass test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm pass 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 broken-job build-armhf broken Not pushing. ------------------------------------------------------------ commit 85688075ccc22c12bd0fca2a2c269199938e104c Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Feb 21 18:10:00 2018 +0000 x86/hvm: Constify the read side of vlapic handling This is in preparation to make hvm_x2apic_msr_read() take a const vcpu pointer. One modification is to alter vlapic_get_tmcct() to not use current. This in turn needs an alteration to hvm_get_guest_time_fixed(), which is safe because the only mutable action it makes is to take the domain plt lock. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 62e80dff59c779cb56755b419120529e3d7eb17d Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon Feb 26 14:23:03 2018 +0000 x86/vmx: Simplfy the default cases in vmx_msr_{read,write}_intercept() The default case of vmx_msr_write_intercept() in particular is very tangled. First of all, fold long_mode_do_msr_{read,write}() into their callers. These functions were split out in the past because of the 32bit build of Xen, but it is unclear why the cases weren't simply #ifdef'd in place. Next, invert the vmx_write_guest_msr()/is_last_branch_msr() logic to break if the condition is satisfied, rather than nesting if it wasn't. This allows the wrmsr_hypervisor_regs() call to be un-nested with respect to the other default logic. No practical difference from a guests point of view. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> commit b68c4f1ebe4f413076c4915733a61c818b7dc73a Author: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> Date: Wed Feb 28 12:38:15 2018 +0200 x86/hvm: fix domain crash when CR3 has the noflush bit set In hardware, when PCID support is enabled and the NOFLUSH bit is set when writing a CR3 value, the hardware will clear that that bit and change the CR3 without flushing the TLB. hvm_set_cr3(), however, was ignoring this bit; the result was that post-vm_event checks detected an invalid CR3 value and crashed the domain. Handle NOFLUSH in hvm_set_cr3() by: 1. Clearing the bit 2. Passing a "noflush" flag to lower-level cr3 setting functions to indicate that a flush should not be performed. Also clear X86_CR3_NOFLUSH when reporting CR3 monitored CR3 writes. This allows introspection to be used on VMs whose operating system uses the NOFLUSH bit. Signed-off-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> Reported-by: Bitweasil <bitweasil@xxxxxxxxxxxxxx> Suggested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Tamas K Lengyel <tamas@xxxxxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@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 |