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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   6 xen-build                fail REGR. vs. 157696

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 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                  d162f36848c4a98a782cc05820b0aa7ec1ae297d
baseline version:
 xen                  357db96a66e47e609c3b14768f1062e13eedbd93

Last test of basis   157696  2020-12-18 19:01:31 Z    2 days
Testing same since   157761  2020-12-21 15:00:25 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                                                  fail    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    blocked 
 test-amd64-amd64-libvirt                                     blocked 


------------------------------------------------------------
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 d162f36848c4a98a782cc05820b0aa7ec1ae297d
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Sep 28 15:25:44 2020 +0100

    xen/x86: Fix memory leak in vcpu_create() error path
    
    Various paths in vcpu_create() end up calling paging_update_paging_modes(),
    which eventually allocate a monitor pagetable if one doesn't exist.
    
    However, an error in vcpu_create() results in the vcpu being cleaned up
    locally, and not put onto the domain's vcpu list.  Therefore, the monitor
    table is not freed by {hap,shadow}_teardown()'s loop.  This is caught by
    assertions later that we've successfully freed the entire hap/shadow memory
    pool.
    
    The per-vcpu loops in domain teardown logic is conceptually wrong, but exist
    due to insufficient existing structure in the existing logic.
    
    Break paging_vcpu_teardown() out of paging_teardown(), with mirrored 
breakouts
    in the hap/shadow code, and use it from arch_vcpu_create()'s error path.  
This
    fixes the memory leak.
    
    The new {hap,shadow}_vcpu_teardown() must be idempotent, and are written to 
be
    as tolerable as possible, with the minimum number of safety checks possible.
    In particular, drop the mfn_valid() check - if these fields are junk, then 
Xen
    is going to explode anyway.
    
    Reported-by: Michał Leszczyński <michal.leszczynski@xxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 6131dab5f2c8059a0fc7fd884bc6d4ff78ba44c2
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Fri Dec 18 23:30:04 2020 +0000

    xen/Kconfig: Correct the NR_CPUS description
    
    The description "physical CPUs" is especially wrong, as it implies the 
number
    of sockets, which tops out at 8 on all but the very biggest servers.
    
    NR_CPUS is the number of logical entities the scheduler can use.
    
    Reported-by: hanetzer@xxxxxxxxxxxxx
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
(qemu changes not included)