|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-4.12-testing test] 138759: regressions - FAIL
flight 138759 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/138759/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-raw 7 xen-boot fail REGR. vs. 137867 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail blocked in 137867 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-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 test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-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 test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 7f2df4b62214645dc15488487da26eb32c7790b4 baseline version: xen f41dbf33e7129846a0468f006fb41fcd888d6612 Last test of basis 137867 2019-06-16 15:04:14 Z 19 days Testing same since 138759 2019-07-05 08:36:41 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Igor Druzhinin <igor.druzhinin@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Kevin Tian <kevin.tian@xxxxxxxxx> Paul Durrant <paul.durrant@xxxxxxxxxx> Sergey Dyasli <sergey.dyasli@xxxxxxxxxx> jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass 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-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-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-xl-qemut-win10-i386 fail test-amd64-i386-xl-qemut-win10-i386 fail test-amd64-amd64-xl-qemuu-win10-i386 fail test-amd64-i386-xl-qemuu-win10-i386 fail test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch 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-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw fail test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd 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 7f2df4b62214645dc15488487da26eb32c7790b4 Author: Paul Durrant <paul.durrant@xxxxxxxxxx> Date: Fri Jul 5 10:25:46 2019 +0200 x86/msi: fix loop termination condition in pci_msi_conf_write_intercept() The for loop that deals with MSI masking is coded as follows: for ( pos = 0; pos < entry->msi.nvec; ++pos, ++entry ) Thus the loop termination condition is dereferencing a struct pointer that is being incremented by the loop. A block of MSI entries stores the number of vectors in entry[0].msi.nvec, with all subsequent entries using a value of 0. Therefore, for a block of two or more MSIs will terminate the loop early, as entry[1].msi.nvec is 0. However, for a single MSI, ++entry moves the pointer out of bounds, and a bogus read is used for the termination condition. In the case that the loop body gets entered, there are subsequent OoB writes which clobber adjacent memory in the heap. This patch simply initializes a stack variable to the value of entry->msi.nvec before starting the loop and then uses that in the termination condition instead. Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: 56ad626532eb7addeef2bb2f5f67a15756b5cee2 master date: 2019-07-02 12:00:42 +0100 commit a5680b190429a207ee968b86364ae486d0b40be2 Author: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx> Date: Fri Jul 5 10:25:01 2019 +0200 x86/vvmx: set CR4 before CR0 Otherwise hvm_set_cr0() will check the wrong CR4 bits (L1 instead of L2 and vice-versa). Signed-off-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> master commit: 3af3c95b81625adf7e6ea71c94b641424741eded master date: 2019-06-28 13:17:53 +0100 commit 675ccffbb20c111db2c2703c26e8e151f993e2e5 Author: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx> Date: Fri Jul 5 10:24:30 2019 +0200 x86/cpuid: leak OSXSAVE only when XSAVE is not clear in policy This fixes booting of old non-PV-OPS kernels which historically looked for OSXSAVE instead of XSAVE bit in CPUID to check whether XSAVE feature is enabled. If such a guest appears to be started on an XSAVE enabled CPU and the feature is explicitly cleared in policy, leaked OSXSAVE bit from Xen will lead to guest crash early in boot. Signed-off-by: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 902888922e6feda2c485cc4bdeffd0d6e6c26e14 master date: 2019-06-28 13:17:53 +0100 commit a0ab0db67ef8a6ba2b2414e397543a6e2cd9be8d Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Jul 5 10:23:34 2019 +0200 x86/SMP: don't try to stop already stopped CPUs In particular with an enabled IOMMU (but not really limited to this case), trying to invoke fixup_irqs() after having already done disable_IO_APIC() -> clear_IO_APIC() is a rather bad idea: RIP: e008:[<ffff82d08026a036>] amd_iommu_read_ioapic_from_ire+0xde/0x113 RFLAGS: 0000000000010006 CONTEXT: hypervisor (d0v0) rax: ffff8320291de00c rbx: 0000000000000003 rcx: ffff832035000000 rdx: 0000000000000000 rsi: 0000000000000000 rdi: ffff82d0805ca840 rbp: ffff83009e8a79c8 rsp: ffff83009e8a79a8 r8: 0000000000000000 r9: 0000000000000004 r10: 000000000008b9f9 r11: 0000000000000006 r12: 0000000000010000 r13: 0000000000000003 r14: 0000000000000000 r15: 00000000fffeffff cr0: 0000000080050033 cr4: 00000000003406e0 cr3: 0000002035d59000 cr2: ffff88824ccb4ee0 fsb: 00007f2143f08840 gsb: ffff888256a00000 gss: 0000000000000000 ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008 Xen code around <ffff82d08026a036> (amd_iommu_read_ioapic_from_ire+0xde/0x113): ff 07 00 00 39 d3 74 02 <0f> 0b 41 81 e4 00 f8 ff ff 8b 10 89 d0 25 00 00 Xen stack trace from rsp=ffff83009e8a79a8: ... Xen call trace: [<ffff82d08026a036>] amd_iommu_read_ioapic_from_ire+0xde/0x113 [<ffff82d08026bf7b>] iommu_read_apic_from_ire+0x10/0x12 [<ffff82d08027f718>] io_apic.c#modify_IO_APIC_irq+0x5e/0x126 [<ffff82d08027f9c5>] io_apic.c#unmask_IO_APIC_irq+0x2d/0x41 [<ffff82d080289bc7>] fixup_irqs+0x320/0x40b [<ffff82d0802a82c4>] smp_send_stop+0x4b/0xa8 [<ffff82d0802a7b2f>] machine_restart+0x98/0x288 [<ffff82d080252242>] console_suspend+0/0x28 [<ffff82d0802b01da>] do_general_protection+0x204/0x24e [<ffff82d080385a3d>] x86_64/entry.S#handle_exception_saved+0x68/0x94 [<00000000aa5b526b>] 00000000aa5b526b [<ffff82d0802a7c7d>] machine_restart+0x1e6/0x288 [<ffff82d080240f75>] hwdom_shutdown+0xa2/0x11d [<ffff82d08020baa2>] domain_shutdown+0x4f/0xd8 [<ffff82d08023fe98>] do_sched_op+0x12f/0x42a [<ffff82d08037e404>] pv_hypercall+0x1e4/0x564 [<ffff82d080385432>] lstar_enter+0x112/0x120 Don't call fixup_irqs() and don't send any IPI if there's only one online CPU anyway, and don't call __stop_this_cpu() at all when the CPU we're on was already marked offline (by a prior invocation of __stop_this_cpu()). Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Extend this to the kexec/crash path as well. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: 6ff560f7f1f214fb89baaf97812c4c943e44a642 master date: 2019-06-18 16:35:35 +0200 commit 353ed67cd6b95135e2794a50a08f861941a46ff5 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Jul 5 10:23:01 2019 +0200 x86/AMD: limit C1E disable family range Just like for other family values of 0x17 (see "x86/AMD: correct certain Fam17 checks"), commit 3157bb4e13 ("Add MSR support for various feature AMD processor families") made the original check for Fam11 here include families all the way up to Fam17. The involved MSR (0xC0010055), however, is fully reserved starting from Fam16, and the two bits of interest are reserved for Fam12 and onwards (albeit I admit I wasn't able to find any Fam13 doc). Restore the upper bound to be Fam11. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 5c2926f576c9127a8d47217e0cafe00cc741c452 master date: 2019-06-18 16:34:51 +0200 commit 3fa73d4acf81e25b5587bf3a5436274ae67d7826 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Jul 5 10:22:27 2019 +0200 x86/AMD: correct certain Fam17 checks Commit 3157bb4e13 ("Add MSR support for various feature AMD processor families") converted certain checks for Fam11 to include families all the way up to Fam17. The commit having no description, it is hard to tell whether this was a mechanical dec->hex conversion mistake, or indeed intended. In any event the NB_CFG handling needs to be restricted to Fam16 and below: Fam17 doesn't really have such an MSR anymore. As per observation it's read-zero / write-discard now, so make PV uniformly (with the exception of pinned Dom0 vCPU-s) behave so, just like HVM already does. Mirror the NB_CFG behavior to MSR_FAM10H_MMIO_CONF_BASE as well, except that here the vendor/model check is kept in place (for now at least). A non-MMCFG extended config space access mechanism still appears to exist, but code to deal with it will need to be written down the road, when it can actually be tested. Reported-by: Pu Wen <puwen@xxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: e0fbf3bf9871b00fa526c4ed893604e7ad6c3090 master date: 2019-06-18 16:33:53 +0200 commit ec3d131d9d64f46bb2d6ab9a16074a15c309f6d8 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Jul 5 10:21:44 2019 +0200 x86/pv: Fix undefined behaviour in check_descriptor() UBSAN reports: (XEN) ================================================================================ (XEN) UBSAN: Undefined behaviour in x86_64/mm.c:1108:31 (XEN) left shift of 255 by 24 places cannot be represented in type 'int' (XEN) ----[ Xen-4.13-unstable x86_64 debug=y Tainted: H ]---- (XEN) CPU: 60 (XEN) RIP: e008:[<ffff82d0802a54ce>] ubsan.c#ubsan_epilogue+0xa/0xc2 <snip> (XEN) Xen call trace: (XEN) [<ffff82d0802a54ce>] ubsan.c#ubsan_epilogue+0xa/0xc2 (XEN) [<ffff82d0802a6009>] __ubsan_handle_shift_out_of_bounds+0x15d/0x16c (XEN) [<ffff82d08033abd7>] check_descriptor+0x191/0x3dd (XEN) [<ffff82d0804ef920>] do_update_descriptor+0x7f/0x2b6 (XEN) [<ffff82d0804efb75>] compat_update_descriptor+0x1e/0x20 (XEN) [<ffff82d0804fa1cc>] pv_hypercall+0x87f/0xa6f (XEN) [<ffff82d080501acb>] do_entry_int82+0x53/0x58 (XEN) [<ffff82d08050702b>] entry_int82+0xbb/0xc0 (XEN) (XEN) ================================================================================ As this is a constant, express it in longhand for correctness, and consistency with the surrounding code. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: bd5be40ce2307ea5e8f52e3103d1b48ca9dfdce9 master date: 2019-06-06 20:04:33 +0100 commit 4c3eb3a6ba7aee71bbcd3adac8205650935a5b72 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Jul 5 10:21:27 2019 +0200 x86/irq: Fix undefined behaviour in irq_move_cleanup_interrupt() UBSAN reports: (XEN) ================================================================================ (XEN) UBSAN: Undefined behaviour in irq.c:682:22 (XEN) left shift of 1 by 31 places cannot be represented in type 'int' (XEN) ----[ Xen-4.13-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: 16 (XEN) RIP: e008:[<ffff82d0802a54ce>] ubsan.c#ubsan_epilogue+0xa/0xc2 <snip> (XEN) Xen call trace: (XEN) [<ffff82d0802a54ce>] ubsan.c#ubsan_epilogue+0xa/0xc2 (XEN) [<ffff82d0802a6009>] __ubsan_handle_shift_out_of_bounds+0x15d/0x16c (XEN) [<ffff82d08031ae77>] irq_move_cleanup_interrupt+0x25c/0x4a0 (XEN) [<ffff82d08031b585>] do_IRQ+0x19d/0x104c (XEN) [<ffff82d08050c8ba>] common_interrupt+0x10a/0x120 (XEN) [<ffff82d0803b13a6>] cpu_idle.c#acpi_idle_do_entry+0x1de/0x24b (XEN) [<ffff82d0803b1d83>] cpu_idle.c#acpi_processor_idle+0x5c8/0x94e (XEN) [<ffff82d0802fa8d6>] domain.c#idle_loop+0xee/0x101 (XEN) (XEN) ================================================================================ Switch to an unsigned shift, and correct the surrounding style. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: 0bf4a2560dd24a7a1285727a900b52adcb4594fb master date: 2019-06-06 20:04:32 +0100 commit 8b162b0ffc157a208808151dc6396ea16c648844 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Jul 5 10:20:39 2019 +0200 x86/spec-ctrl: Knights Landing/Mill are retpoline-safe They are both Airmont-based and should have been included in c/s 17f74242ccf "x86/spec-ctrl: Extend repoline safey calcuations for eIBRS and Atom parts". Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: e2105180f99d22aad47ee57113015e11d7397e54 master date: 2019-05-31 19:11:29 +0100 commit 6922d07adacb2360ebf0d7511a4e530b05e45c74 Author: Paul Durrant <paul.durrant@xxxxxxxxxx> Date: Fri Jul 5 10:19:12 2019 +0200 x86/vhpet: avoid 'small' time diff test on resume It appears that even 64-bit versions of Windows 10, when not using syth- etic timers, will use 32-bit HPET non-periodic timers. There is a test in hpet_set_timer(), specific to 32-bit timers, that tries to disambiguate between a comparator value that is in the past and one that is sufficiently far in the future that it wraps. This is done by assuming that the delta between the main counter and comparator will be 'small' [1], if the comparator value is in the past. Unfortunately, more often than not, this is not the case if the timer is being re-started after a migrate and so the timer is set to fire far in the future (in excess of a minute in several observed cases) rather then set to fire immediately. This has a rather odd symptom where the guest console is alive enough to be able to deal with mouse pointer re-rendering, but any keyboard activity or mouse clicks yield no response. This patch simply adds an extra check of 'creation_finished' into hpet_set_timer() so that the 'small' time test is omitted when the function is called to restart timers after migration, and thus any negative delta causes a timer to fire immediately. [1] The number of ticks that equate to 0.9765625 milliseconds Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: b144cf45d50b603c2909fc32c6abf7359f86f1aa master date: 2019-05-31 11:40:52 +0200 (qemu changes not included) _______________________________________________ osstest-output mailing list osstest-output@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/osstest-output
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |