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

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

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

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. 
133343

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>

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-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
    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 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 
change
    is going to need to call altp2m_vcpu_disable_ve() from the domain_kill() 
path.
    
    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 
a
    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
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel