[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [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)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.