[xen-unstable-smoke test] 159709: regressions - FAIL

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

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  c4441ab1f1d506a942002ccc55fdde2fe30ef626
baseline version:
 xen                  109e8177fd4a225e7025c4c17d2c9537b550b4ed

Last test of basis   159704  2021-02-26 10:01:26 Z    0 days
Testing same since   159709  2021-02-26 13:00:30 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

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-amd64                    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 c4441ab1f1d506a942002ccc55fdde2fe30ef626
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Feb 25 15:46:10 2021 +0000

    dmop: Add XEN_DMOP_nr_vcpus
    
    Curiously absent from the stable API/ABIs is an ability to query the number 
of
    vcpus which a domain has.  Emulators need to know this information in
    particular to know how many stuct ioreq's live in the ioreq server mappings.
    
    In practice, this forces all userspace to link against libxenctrl to use
    xc_domain_getinfo(), which rather defeats the purpose of the stable 
libraries.
    
    Introduce a DMOP to retrieve this information and surface it in
    libxendevicemodel to help emulators shed their use of unstable interfaces.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Release-Acked-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>
    ---
    CC: Jan Beulich <JBeulich@xxxxxxxx>
    CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    CC: Wei Liu <wl@xxxxxxx>
    CC: Paul Durrant <paul@xxxxxxx>
    CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    CC: Julien Grall <julien@xxxxxxx>
    CC: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
    CC: Ian Jackson <iwj@xxxxxxxxxxxxxx>
    
    For 4.15.  This was a surprise discovery in the massive ABI untangling 
effort
    I'm currently doing for XenServer's new build system.
    
    This is one new read-only op to obtain information which isn't otherwise
    available under a stable API/ABI.  As such, its risk for 4.15 is very low,
    with a very real quality-of-life improvement for downstreams.
    
    I realise this is technically a new feature and we're long past feature
    freeze, but I'm hoping that "really lets some emulators move off the 
unstable
    libraries" is sufficiently convincing argument.
    
    It's not sufficient to let Qemu move off unstable libraries yet - at a
    minimum, the add_to_phymap hypercalls need stabilising to support PCI
    Passthrough and BAR remapping.
    
    I'd prefer not to duplicate the op handling between ARM and x86, and if this
    weren't a release window, I'd submit a prereq patch to dedup the common dmop
    handling.  That can wait to 4.16 at this point.  Also, this op ought to work
    against x86 PV guests, but fixing that up will also need this rearrangement
    into common code, so needs to wait.

commit 615367b5275a5b0123f1f1ee86c985fab234a5a4
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Feb 25 16:54:17 2021 +0000

    x86/dmop: Properly fail for PV guests
    
    The current code has an early exit for PV guests, but it returns 0 having 
done
    nothing.
    
    Fixes: 524a98c2ac5 ("public / x86: introduce __HYPERCALL_dm_op...")
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Release-Acked-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>
(qemu changes not included)