|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable-smoke test] 141755: regressions - FAIL
flight 141755 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141755/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 141718 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 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 df29d03f1d97bdde1bc0cea8ef8538d4f524b3ec baseline version: xen c4a5656b2ef3d29bb8acfb5342e786a5b9578018 Last test of basis 141718 2019-09-23 15:02:34 Z 0 days Testing same since 141755 2019-09-24 09:02:13 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Paul Durrant <paul@xxxxxxx> Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> 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 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail 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 df29d03f1d97bdde1bc0cea8ef8538d4f524b3ec Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Sep 24 10:50:33 2019 +0200 libxc/x86: avoid certain overflows in CPUID APIC ID adjustments Recent AMD processors may report up to 128 logical processors in CPUID leaf 1. Doubling this value produces 0 (which OSes sincerely dislike), as the respective field is only 8 bits wide. Suppress doubling the value (and its leaf 0x80000008 counterpart) in such a case. Note that while there's a similar overflow in intel_xc_cpuid_policy(), that one is being left alone for now. Note further that while it was considered to suppress the multiplication by 2 altogether if the host topology already provides at least one bit of thread ID within APIC IDs, it was decided to avoid more change here than really needed at this point. Also zap leaf 4 (and at the same time leaf 2) EDX output for AMD, as it should have been from the beginning. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit b8443cb39b04a6449e0d093b62f10c5a89775a78 Author: Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx> Date: Tue Sep 24 10:49:36 2019 +0200 x86/emulate: send vm_event from emulate A/D bit writes (on page walks) can be considered benign by an introspection agent, so receiving vm_events for them is a pessimization. We try here to optimize by filtering these events out. Currently, we are fully emulating the instruction at RIP when the hardware sees an EPT fault with npfec.kind != npfec_kind_with_gla. This is, however, incorrect, because the instruction at RIP might legitimately cause an EPT fault of its own while accessing a _different_ page from the original one, where A/D were set. The solution is to perform the whole emulation, while ignoring EPT restrictions for the walk part, and taking them into account for the "actual" emulating of the instruction at RIP. When we send out a vm_event, we don't want the emulation to complete, since in that case we won't be able to veto whatever it is doing. That would mean that we can't actually prevent any malicious activity, instead we'd only be able to report on it. When we see a "send-vm_event" case while emulating, we need to first send the event out and then suspend the emulation (return X86EMUL_RETRY). After the emulation stops we'll call hvm_vm_event_do_resume() again after the introspection agent treats the event and resumes the guest. There, the instruction at RIP will be fully emulated (with the EPT ignored) if the introspection application allows it, and the guest will continue to run past the instruction. A common example is if the hardware exits because of an EPT fault caused by a page walk, p2m_mem_access_check() decides if it is going to send a vm_event. If the vm_event was sent and it would be treated so it runs the instruction at RIP, that instruction might also hit a protected page and provoke a vm_event. Now if npfec.kind == npfec_kind_in_gpt and d->arch.monitor.inguest_pagefault_disabled is true then we are in the page walk case and we can do this emulation optimization and emulate the page walk while ignoring the EPT, but don't ignore the EPT for the emulation of the actual instruction. In the first case we would have 2 EPT events, in the second case we would have 1 EPT event if the instruction at the RIP triggers an EPT event. We use hvmemul_map_linear_addr() to intercept write access and __hvm_copy() to intercept exec, read and write access. A new return type was added, HVMTRANS_need_retry, in order to have all the places that consume HVMTRANS* return X86EMUL_RETRY. hvm_emulate_send_vm_event() can return false if there was no violation, if there was an error from monitor_traps() or p2m_get_mem_access(). -ESRCH from p2m_get_mem_access() is treated as restricted access. NOTE: hvm_emulate_send_vm_event() assumes the caller will enable/disable arch.vm_event->send_event Signed-off-by: Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx> Acked-by: Paul Durrant <paul@xxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> Reviewed-by: Petre Pircalabu <ppircalabu@xxxxxxxxxxxxxxx> commit 445891bb8ea77ebc9bee98c4507b077d96928521 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Sep 24 10:48:44 2019 +0200 x86/traps: widen condition for logging top-of-stack Despite -fno-omit-frame-pointer the compiler may omit the frame pointer, often for relatively simple leaf functions. (To give a specific example, the case I've run into this with is _pci_hide_device() and gcc 8. Interestingly the even more simple neighboring iommu_has_feature() does get a frame pointer set up, around just a single instruction. But this may be a result of the size-of-asm() effects discussed elsewhere.) Log the top-of-stack value if it looks valid _or_ if RIP looks invalid. Also annotate all stack trace entries with a marker, to indicate their origin: R: register state F: frame pointer based S: raw stack contents Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit 22c419eec6e037a0f8234be97a5ee057bdc89ee4 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Sep 24 10:47:53 2019 +0200 x86/traps: guard top-of-stack reads Nothing guarantees that the original frame's stack pointer points at readable memory. Avoid a (likely nested) crash by attaching exception recovery to the read (making it a single read at the same time). Don't even invoke _show_trace() in case of a non-readable top slot. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> (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 |