All of lore.kernel.org
 help / color / mirror / Atom feed
From: osstest service owner <osstest-admin@xenproject.org>
To: xen-devel@lists.xensource.com, osstest-admin@xenproject.org
Subject: [xen-unstable-coverity test] 101343: regressions - ALL FAIL
Date: Sun, 09 Oct 2016 09:49:49 +0000	[thread overview]
Message-ID: <osstest-101343-mainreport@xen.org> (raw)

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

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                  84c1e7d8017c773c41d6e8b79384f37a67be1479
baseline version:
 xen                  b7dd797c7fe4cd849018f78f6c7b9eb3d33b89d8

Last test of basis   101279  2016-10-05 09:19:19 Z    4 days
Testing same since   101343  2016-10-09 09:18:41 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Lan Tianyu <tianyu.lan@intel.com>
  Razvan Cojocaru <rcojocaru@bitdefender.com>

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 84c1e7d8017c773c41d6e8b79384f37a67be1479
Author: Razvan Cojocaru <rcojocaru@bitdefender.com>
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@suse.com>
    Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>

commit ed7e33747da83ce805c00cd457e71075e34f0854
Author: Lan Tianyu <tianyu.lan@intel.com>
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@intel.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 9f5eff08a6a6f58645fb48382c843973674042c9
Author: Jan Beulich <jbeulich@suse.com>
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@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper@citrix.com>

commit beeeaa920049c88af035b3dee8e20926d9d426f8
Author: Jan Beulich <jbeulich@suse.com>
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@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

commit cab9638a42457d2ab360c60ec419cdef4c75ca54
Author: Jan Beulich <jbeulich@suse.com>
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@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
(qemu changes not included)

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

                 reply	other threads:[~2016-10-09  9:49 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=osstest-101343-mainreport@xen.org \
    --to=osstest-admin@xenproject.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.