[Xen-devel] [xen-unstable-coverity test] 101393: regressions - ALL FAIL

[osstest service owner <osstest-admin@xxxxxxxxxxxxxx>]

flight 101393 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101393/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 coverity-amd64                6 coverity-upload          fail REGR. vs. 101279

version targeted for testing:
 xen                  71b8b46111219a2f83f4f9ae06ac5409744ea86e
baseline version:
 xen                  b7dd797c7fe4cd849018f78f6c7b9eb3d33b89d8

Last test of basis   101279  2016-10-05 09:19:19 Z    7 days
Failing since        101343  2016-10-09 09:18:41 Z    3 days    2 attempts
Testing same since   101393  2016-10-12 09:19:33 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@xxxxxxxxxx>
  Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
  Lan Tianyu <tianyu.lan@xxxxxxxxx>
  Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  Stefano Stabellini <sstabellini@xxxxxxxxxx>
  Wei Liu <wei.liu2@xxxxxxxxxx>

jobs:
 coverity-amd64                                               fail    


------------------------------------------------------------
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 71b8b46111219a2f83f4f9ae06ac5409744ea86e
Author: George Dunlap <george.dunlap@xxxxxxxxxx>
Date:   Fri Sep 30 15:42:56 2016 +0100

    xen/trace: Fix trace metadata page count calculation (revert fbf96e6)
    
    Changeset fbf96e6, "xentrace: correct formula to calculate
    t_info_pages", broke the trace metadata page count calculation, by
    mistaking t_info_first_offset as denominated in bytes, when in fact it
    is denominated in words (uint32_t).
    
    Effectively revert that change, and put a comment there to reduce the
    chance that someone will make that mistake in the future.
    
    Reviewed-by: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
    Tested-by: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
    Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>

commit 68dc7185cbffab34211c77339874f2ea517990fd
Author: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date:   Mon Oct 10 11:10:56 2016 -0700

    Makefile: fix (again) EFI part of "symbols: Generate an xen-sym.map
    
    This is a follow-up to commit d14fffcc6a7c054db9e337026a3c850152244ac4
    "fix EFI part of "symbols: Generate an xen-sym.map" which fixed most of
    the issues.
    
    However we still have an issue - The file being installed (xen.efi.map)
    does not exist in an ARM64 build (the xen.efi is linked againts xen).
    
    The fix can be done two ways:
     a) See if xen.efi.map exists and then copy it
     b) Or link xen.efi.map to xen-syms.map (similar to how xen.efi is linked
        against xen).
    
    The patch chooses the former.
    
    Reported-by: Jan Beulich <JBeulich@xxxxxxxx>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
    Signed-off-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit 0a9d8a57e1f9024459e613e831905d28ef72051a
Author: Wei Liu <wei.liu2@xxxxxxxxxx>
Date:   Mon Oct 10 10:40:30 2016 +0100

    Kconfig: use tab instead of space
    
    Previously in d6be2cfc ("xen: make clear gcov support limitation in
    Kconfig") and db6c2264 ("xen: add a gcov Kconfig option"), space was
    used to indent Kconfig text. Change that to use tab instead.
    
    No functional change.
    
    Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 78ff18c905318a9b1e5dd32662986f03b10a4e56
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Mon Oct 10 12:16:49 2016 +0200

    x86: defer not-present segment checks
    
    Following on from commits 5602e74c60 ("x86emul: correct loading of
    %ss") and bdb860d01c ("x86/HVM: correct segment register loading during
    task switch") the point of the non-.present checks needs to be refined:
    #NP (and its #SS companion), other than suggested by the various
    instruction pages in Intel's SDM, gets checked for only after all type
    and permission checks. The only checks getting done even later are the
    long mode specific ones for system descriptors (which we don't support
    yet) and 64-bit code segments (i.e. anything touching other than the
    attribute byte).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 62c12fa3b15caf54cb8436458a86a1acf42170fd
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Mon Oct 10 12:16:06 2016 +0200

    x86: replace redundant MTRR MSR definitions
    
    We really should have only one set of #define-s for them.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 84c1e7d8017c773c41d6e8b79384f37a67be1479
Author: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
Date:   Fri Oct 7 11:35:58 2016 +0200

    x86/hvm: remove emulation context setting from hvmemul_cmpxchg()
    
    hvmemul_cmpxchg() sets the read emulation context in p_new instead
    of p_old, which is inconsistent (and wrong). Since p_old is
    unused in any case and cmpxchg() semantics would be altered even
    if it wasn't, remove the emulation context setting code.
    
    Suggested-by: Jan Beulich <jbeulich@xxxxxxxx>
    Signed-off-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>

commit ed7e33747da83ce805c00cd457e71075e34f0854
Author: Lan Tianyu <tianyu.lan@xxxxxxxxx>
Date:   Fri Oct 7 11:35:26 2016 +0200

    timer: process softirq during dumping timer info
    
    Dumping timer info may run for a long time on the huge machine with
    a lot of physical cpus. To avoid triggering NMI watchdog, add
    process_pending_softirqs() in the loop of dumping timer info.
    
    Signed-off-by: Lan Tianyu <tianyu.lan@xxxxxxxxx>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>

commit 9f5eff08a6a6f58645fb48382c843973674042c9
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Oct 5 14:20:10 2016 +0200

    x86emul: check for FPU availability
    
    We can't exclude someone wanting to hide the FPU from guests.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper@xxxxxxxxxx>

commit beeeaa920049c88af035b3dee8e20926d9d426f8
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Oct 5 14:19:43 2016 +0200

    x86emul: deliver correct math exceptions
    
    #MF only applies to x87 instructions. SSE and AVX ones need #XM to be
    raised instead, unless CR4.OSXMMEXCPT is clear, in which case #UD needs
    to result. (But note that this is only a latent issue - we don't
    emulate any instructions so far which could result in #XM.)
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit cab9638a42457d2ab360c60ec419cdef4c75ca54
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Oct 5 14:18:42 2016 +0200

    x86emul: honor guest CR4.OSFXSR and CR4.OSXSAVE
    
    These checks belong into the emulator instead of hvmemul_get_fpu().
    
    The CR0.PE/EFLAGS.VM ones can actually just be ASSERT()ed, as decoding
    should make it impossible to get into get_fpu() with them in the wrong
    state.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel