|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.5-testing baseline-only test] 38118: regressions - FAIL
This run is configured for baseline tests only. flight 38118 xen-4.5-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38118/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 21 guest-start/debian.repeat fail REGR. vs. 38021 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 6 xen-boot fail REGR. vs. 38021 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 38021 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate.2 fail like 38021 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail never pass test-armhf-armhf-xl-raw 9 debian-di-install fail never pass test-armhf-armhf-libvirt-vhd 9 debian-di-install fail never pass test-armhf-armhf-xl-vhd 9 debian-di-install fail never pass test-armhf-armhf-xl-qcow2 9 debian-di-install fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-raw 9 debian-di-install fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass test-armhf-armhf-xl-midway 13 saverestore-support-check fail never pass test-armhf-armhf-xl-midway 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 guest-saverestore fail never pass test-armhf-armhf-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass test-amd64-i386-libvirt 12 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-xl 12 migrate-support-check fail never pass test-armhf-armhf-xl 13 saverestore-support-check fail never pass test-amd64-i386-libvirt-vhd 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 11 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass version targeted for testing: xen 0297baf5b5b6724e006e761249694444204dacfb baseline version: xen bbbd29a25d090f1180d14210358c6d7ccdebef85 Last test of basis 38021 2015-09-22 18:25:16 Z 10 days Testing same since 38118 2015-10-02 12:55:22 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Ian Campbell <ian.campbell@xxxxxxxxxx> Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Julien Grall <julien.grall@xxxxxxxxxx> Kouya Shimura <kouya@xxxxxxxxxxxxxx> Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-armhf-pvops pass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 fail test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-credit2 fail test-armhf-armhf-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumpuserxen-i386 pass test-amd64-amd64-xl-pvh-intel fail test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass test-armhf-armhf-xl-midway pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 fail test-amd64-i386-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-xl-qcow2 fail test-amd64-i386-xl-qcow2 pass test-amd64-amd64-libvirt-raw pass test-armhf-armhf-libvirt-raw fail test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-raw pass test-armhf-armhf-xl-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-libvirt-vhd fail test-amd64-i386-libvirt-vhd pass test-amd64-amd64-xl-vhd pass test-armhf-armhf-xl-vhd fail test-amd64-i386-xl-vhd pass test-amd64-amd64-xl-qemut-winxpsp3 pass test-amd64-i386-xl-qemut-winxpsp3 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3 pass ------------------------------------------------------------ sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ------------------------------------------------------------ commit 0297baf5b5b6724e006e761249694444204dacfb Author: Julien Grall <julien.grall@xxxxxxxxxx> Date: Fri Sep 25 14:10:06 2015 +0100 xen/arm: vgic-v2: Map the GIC virtual CPU interface with the correct size On GICv2, the GIC virtual CPU interface is at minimum 8KB. Due some to some necessary quirk for GIC using 64KB stride, we are mapping the region in 2 time. The first mapping is 4KB and the second one is 8KB, i.e 12KB in total. Although the minimum supported size (and widely used) is 8KB. This means that we are mapping 4KB more to any guest using GICv2. While this looks scary at first glance, the GIC virtual CPU interface is most frequently at the end the GIC I/O region. So we will most likely map an an unused I/O region or a mirrored version of GICV for platform using 64KB stride. Nonetheless, fix the second mapping to only map 4KB. Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> (Backported from 493a67ee4a3fd9420e94fa2cf108e2a27961202b) commit 9b147f96ae69cadafc853a544a7526b1740b053c Author: Julien Grall <julien.grall@xxxxxxxxxx> Date: Tue Sep 22 21:18:48 2015 +0100 xen/arm: vgic: Correctly emulate write when byte is used When a guest is writing a byte, the value will be located in bits[7:0] of the register. Although the current implementation is expecting the byte at the Nth byte of the register where N = address & 4; When the address is not 4-byte aligned, the corresponding byte in the internal state will always be set to zero rather. Note that byte access are only used for GICD_IPRIORITYR and GICD_ITARGETSR. So the worst things that could happen is not setting the priority correctly and ignore the target vCPU written. Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> (cherry picked from commit 3f214fea76acc6cbc1101fe1815cee795483a67d) commit f72ab694c5a6143aac965e912351ae6350dd1089 Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Thu Jul 16 09:50:07 2015 +0100 xen: arm: bootfdt: Avoid reading off the front of *_cells array In device_tree_for_each_node the call to the callback was using {address,size}_cells[depth - 1], which at depth 0 could read off the front of the array. We already handled this correctly in the rest of the loop so fixup this instance as well. Reported-by: Chris (Christopher) Brand <chris.brand@xxxxxxxxxxxx> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Cc: Chris (Christopher) Brand <chris.brand@xxxxxxxxxxxx> Reviewed-by: Julien Grall <julien.grall@xxxxxxxxxx> (cherry picked from commit 989f3939bd16a0e1669c179b6c5c264812a25fc2) commit c562986357d04c49aaa8c678f27b0a70294dffef Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Mon Mar 30 12:12:35 2015 +0100 xen: arm: always omit guest user stack in vcpu_show_execution_state Using !usr_mode(regs) only catches arm32 usr mode and not arm64 user mode, switch to psr_mode_is_user instead. Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Reviewed-by: Julien Grall <julien.grall@xxxxxxxxxx> (cherry picked from commit ceb7d6b66de21810a837389911eb2f40c1ca6222) commit 12cc60d994fd1a6a95766015b587ec252ee2bc9c Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Mon Mar 30 12:12:24 2015 +0100 xen: arm: handle accesses to CNTP_CVAL_EL0 All OSes we have run on top of Xen use CNTP_TVAL_EL0 but for completeness we really should handle CVAL too. In vtimer_emulate_cp64 pull the propagation of the 64-bit result into two 32-bit registers out of the switch to avoid duplicating for every register. We also need to initialise x now since previously the only register implemented register was R/O. While adding HSR_SYSREG_CNTP_CVAL_EL0 also move HSR_SYSREG_CNTP_CTL_EL0 so it is sorted correctly. Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Reviewed-by: Julien Grall <julien.grall@xxxxxxxxxx> (cherry picked from commit 9cfa8ebe2e82d38c2e0c32fa23ea920a43e414ca) commit 2b0d3714cb4c2d422775ea63b300de0edfe26f06 Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Mon Mar 30 12:12:23 2015 +0100 xen: arm: correctly handle vtimer traps from userspace Previously 32-bit userspace on 32-bit kernel and 64-bit userspace on 64-bit kernel could access these registers irrespective of whether the kernel had configured them to be allowed to. To fix this: - Userspace access to CNTP_CTL_EL0 and CNTP_TVAL_EL0 should be gated on CNTKCTL_EL1.EL0PTEN. - Userspace access to CNTPCT_EL0 should be gated on CNTKCTL_EL1.EL0PCTEN. When we do not handle an access we now silently inject an undef even in debug mode since the debugging messages are not helpful (we have handled the access, by explicitly choosing not to). The usermode accessibility check is rather repetitive, so a helper macro is introduced. Since HSR_EC_CP15_64 cannot be taken from a guest in AArch64 mode except due to a hardware bug switch the associated check to a BUG_ON (which will be switched to something more appropriate in a subsequent patch) Fix a coding style issue in HSR_CPREG64(CNTPCT) while touching similar code. Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Reviewed-by: Julien Grall <julien.grall@xxxxxxxxxx> (cherry picked from commit d306211e2131eb2d160522f21f21fceaa9dd054c) Conflicts: xen/arch/arm/traps.c commit 9bed9188dd5b0923988615021b3bec17522ec985 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Sep 23 09:08:49 2015 +0200 x86/sysctl: don't clobber memory if NCAPINTS > ARRAY_SIZE(pi->hw_cap) There is no current problem, as both NCAPINTS and pi->hw_cap are 8 entries, but the limit should be calculated appropriately so as to avoid hypervisor stack corruption if the two do get out of sync. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: c373b912e74659f0e0898ae93e89513694cfd94e master date: 2015-09-16 11:22:00 +0200 commit bda02ca86f323779e5be700eb4de50bbcd8e7e63 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Sep 23 09:08:22 2015 +0200 x86/MSI: fail if no hardware support This is to guard against buggy callers (luckily Dom0 only) invoking the respective hypercall for a device not being MSI-capable. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: c7d5d5d8ea1ecbd6ef8b47dace4dec825f0f6e48 master date: 2015-09-16 11:20:27 +0200 commit 33562a45c6497b53fb0cd42b9a1433dba6c3273e Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Sep 23 09:07:52 2015 +0200 x86/p2m: fix mismatched unlock Luckily, due to gfn_unlock() currently mapping to p2m_unlock(), this is only a cosmetic issue right now. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx> master commit: 1f180822ad3fe83fe293393ec175f14ded98f082 master date: 2015-09-14 13:39:19 +0200 commit fe842225f2d2dd71c97cff7ce2cea157328c4e9c Author: Kouya Shimura <kouya@xxxxxxxxxxxxxx> Date: Wed Sep 23 09:07:18 2015 +0200 x86/hvm: fix saved pmtimer and hpet values The ACPI PM timer is sometimes broken on live migration. Since vcpu->arch.hvm_vcpu.guest_time is always zero in other than "delay for missed ticks mode". Even in "delay for missed ticks mode", vcpu's guest_time field is not valid (i.e. zero) when the state of vcpu is "blocked". (see pt_save_timer function) The original author (Tim Deegan) of pmtimer_save() must have intended that it saves the last scheduled time of the vcpu. Unfortunately it was already implied this bug. FYI, there is no other timer mode than "delay for missed ticks mode" then. For consistency with HPET, pmtimer_save() should refer hvm_get_guest_time() to update the counter as well as hpet_save() does. Without this patch, the clock of windows server 2012R2 without HPET might leap forward several minutes on live migration. Signed-off-by: Kouya Shimura <kouya@xxxxxxxxxxxxxx> Retain use of ->arch.hvm_vcpu.guest_time when non-zero. Do the inverse adjustment for vHPET. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Tim Deegan <tim@xxxxxxx> Reviewed-by: Kouya Shimura <kouya@xxxxxxxxxxxxxx> master commit: 244582a01dcb49fa30083725964a066937cc94f2 master date: 2015-09-11 16:24:56 +0200 commit bfa874d7ce12e2903a050ed8173687f75cae789e Author: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> Date: Wed Sep 23 09:06:00 2015 +0200 efi: introduce efi_arch_flush_dcache_area Objects loaded by FileHandle->Read need to be flushed from dcache, otherwise copy_from_paddr will read stale data when copying the kernel, causing a failure to boot. Introduce efi_arch_flush_dcache_area and call it from read_file. This commit introduces no functional changes on x86. Reported-by: Mark Rutland <mark.rutland@xxxxxxx> Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> master commit: 0d6a3c755374f04f6dd25373da28291a8f35bede master date: 2015-09-09 15:29:06 +0200 commit 0619913669efc834877c9d08c98ed58cb8459e7e Author: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> Date: Tue Sep 22 16:56:18 2015 +0100 libxl: handle read-only drives with qemu-xen The current libxl code doesn't deal with read-only drives at all. Upstream QEMU and qemu-xen only support read-only cdrom drives: make sure to specify "readonly=on" for cdrom drives and return error in case the user requested a non-cdrom read-only drive. This is XSA-142, discovered by Lin Liu (https://bugzilla.redhat.com/show_bug.cgi?id=1257893). Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> Backport to Xen 4.5 and earlier, apropos of report and review from Michael Young. Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |