[Xen-devel] [xen-unstable-smoke test] 122632: regressions - trouble: blocked/broken/pass

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf                     <job status>                 broken
 build-armhf                   5 host-build-prep          fail REGR. vs. 122620

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 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                  3abe241190af31760c506a9f32bf25e958ea060c
baseline version:
 xen                  e38e285a51c805cfeee4693962df23e39b3c3bd7

Last test of basis   122620  2018-05-05 21:05:34 Z    1 days
Testing same since   122632  2018-05-07 08:01:17 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                                                  broken  
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386                     pass    
 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

broken-job build-armhf broken

Not pushing.

------------------------------------------------------------
commit 3abe241190af31760c506a9f32bf25e958ea060c
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Mon May 7 09:12:16 2018 +0200

    SVM: introduce a VM entry helper
    
    Neither the register values copying nor the trace entry generation need
    doing in assembly. The VMLOAD invocation can also be further deferred
    (and centralized). Therefore replace the svm_asid_handle_vmrun()
    invocation with one of the new helper.
    
    Similarly move the VM exit side register value copying into
    svm_vmexit_handler().
    
    Now that we always make it out to guest context after VMLOAD,
    svm_sync_vmcb() no longer overrides vmcb_needs_vmsave, making
    svm_vmexit_handler() setting the field early unnecessary.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>

commit cb6ff207f7e0bbfe2d9ab3cb1a0866962cf17169
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Mon May 7 09:11:15 2018 +0200

    SVM: re-work VMCB sync-ing
    
    While the main problem to be addressed here is the issue of what so far
    was named "vmcb_in_sync" starting out with the wrong value (should have
    been true instead of false, to prevent performing a VMSAVE without ever
    having VMLOADed the vCPU's state), go a step further and make the
    sync-ed state a tristate: CPU and memory may be in sync or an update
    may be required in either direction. Rename the field and introduce an
    enum. Callers of svm_sync_vmcb() now indicate the intended new state
    (with a slight "anomaly" when requesting VMLOAD: we could store
    vmcb_needs_vmsave in those cases as the callers request, but the VMCB
    really is in sync at that point, and hence there's no need to VMSAVE in
    case we don't make it out to guest context), and all syncing goes
    through that function.
    
    With that, there's no need to VMLOAD the state perhaps multiple times;
    all that's needed is loading it once before VM entry.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    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