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

Regressions :-(

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

version targeted for testing:
 xen                  451004603247205467ec34b366b4cfa3814a5d95
baseline version:
 xen                  913acc1aa019054742217926dea0827e7a9df02e

Last test of basis   121767  2018-04-04 09:39:19 Z    4 days
Testing same since   122088  2018-04-08 09:25:13 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.coop...@citrix.com>
  Petre Pircalabu <ppircal...@bitdefender.com>
  Razvan Cojocaru <rcojoc...@bitdefender.com>
  Sergey Dyasli <sergey.dya...@citrix.com>
  Wei Liu <wei.l...@citrix.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 451004603247205467ec34b366b4cfa3814a5d95
Author: Sergey Dyasli <sergey.dya...@citrix.com>
Date:   Thu Mar 22 11:32:36 2018 +0000

    x86/cpuid: update signature of hvm_cr4_guest_valid_bits()
    
    With the new cpuid infrastructure there is a domain-wide struct cpuid
    policy and there is no need to pass a separate struct vcpu * into
    hvm_cr4_guest_valid_bits() anymore. Make the function accept struct
    domain * instead and update callers.
    
    Signed-off-by: Sergey Dyasli <sergey.dya...@citrix.com>
    Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com>
    Reviewed-by: Kevin Tian <kevin.t...@intel.com>

commit 9383de210e747f15d0fd10ade89e35d543fbc4e8
Author: Razvan Cojocaru <rcojoc...@bitdefender.com>
Date:   Fri Mar 30 18:39:05 2018 +0300

    x86/altp2m: support for setting restrictions for an array of pages
    
    For the default EPT view we have xc_set_mem_access_multi(), which
    is able to set an array of pages to an array of access rights with
    a single hypercall. However, this functionality was lacking for the
    altp2m subsystem, which could only set page restrictions for one
    page at a time. This patch addresses the gap.
    
    HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
    DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart 
(and
    hence with the original altp2m design, where domains are allowed - with the
    proper altp2m access rights - to alter these settings), in the absence of an
    official position on the issue from the original altp2m designers.
    
    Signed-off-by: Razvan Cojocaru <rcojoc...@bitdefender.com>
    Signed-off-by: Petre Pircalabu <ppircal...@bitdefender.com>
    Acked-by: Wei Liu <wei.l...@citrix.com>
    Reviewed-by: George Dunlap <george.dun...@citrix.com>

commit 90eff18cc5e16e0749605d88092ecfa4ab126c8f
Author: Wei Liu <wei.l...@citrix.com>
Date:   Wed Apr 4 12:03:14 2018 +0100

    x86/hvm/ioreq: fix two bugs in hvm_create_ioreq_server
    
    It is possible to call the error path with i pointing beyond the end
    of the array.
    
    There is another bug that if there is already a default ioreq server,
    the code will actually sets the element to NULL, hence leaking memory.
    
    Move setting NULL to where it is needed.
    
    Coverity-ID: 1433777
    Signed-off-by: Wei Liu <wei.l...@citrix.com>
    Reviewed-by: Paul Durrant <paul.durr...@citrix.com>
    Acked-by: Andrew Cooper <andrew.coop...@citrix.com>
(qemu changes not included)

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

Reply via email to