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

[Xen-devel] [xen-unstable-smoke test] 133371: regressions - FAIL

flight 133371 xen-unstable-smoke real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 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

version targeted for testing:
 xen                  e72ecc7615410e5bf1a1c9a4c7772322c16eeb82
baseline version:
 xen                  db2af23d15077605f286d8ef86c8f5d9c1b8302a

Last test of basis   133343  2019-02-21 03:00:49 Z    1 days
Testing same since   133371  2019-02-22 15:00:34 Z    0 days    1 attempts

People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>

 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-i386                     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

Explanation of these reports, and of osstest in general, is at

Test harness code can be found at

Not pushing.

commit e72ecc7615410e5bf1a1c9a4c7772322c16eeb82
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Jan 17 12:26:17 2019 +0000

    x86/altp2m: Rework #VE enable/disable paths
    Split altp2m_vcpu_{enable,disable}_ve() out of the
    HVMOP_altp2m_vcpu_{enable,disable}_notify marshalling logic.  A future 
    is going to need to call altp2m_vcpu_disable_ve() from the domain_kill() 
    While at it, clean up the logic in altp2m_vcpu_{initialise,destroy}().
    altp2m_vcpu_reset() has no external callers, so fold it into its two
    callsites.  This in turn allows for altp2m_vcpu_destroy() to reuse
    altp2m_vcpu_disable_ve() rather than opencoding it.
    No practical change.
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>

commit 0dfffe01d5681ede6a50c6b57131320d9f4a3361
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Feb 20 13:39:20 2019 +0000

    x86: Improve the efficiency of domain_relinquish_resources()
    pci_release_devices() takes the global PCI lock.  Once pci_release_devices()
    has completed, it will be called redundantly each time paging_teardown() and
    vcpu_destroy_pagetables() continue.
    This is liable to be millions of times for a reasonably sized guest, and is 
    serialising bottleneck now that domain_kill() can be run concurrently on
    different domains.
    Instead of propagating the opencoding of the relinquish state machine, take
    the opportunity to clean it up.
    Leave a proper set of comments explaining that domain_relinquish_resources()
    implements a co-routine.  Introduce a documented PROGRESS() macro to avoid
    latent bugs such as the RELMEM_xen case, and make the new PROG_* states
    private to domain_relinquish_resources().
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>
(qemu changes not included)

Xen-devel mailing list



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