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

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

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

Regressions :-(

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

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                  e6e85b662be9eab96f4cfc58e9945580cce8b2bb
baseline version:
 xen                  3059178798a23ba870ff86ff54d442a07e6651fc

Last test of basis   156622  2020-11-10 13:01:19 Z    0 days
Testing same since   156628  2020-11-10 17:00:28 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Juergen Gross <jgross@xxxxxxxx>
  Julien Grall <jgrall@xxxxxxxxxx>

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 e6e85b662be9eab96f4cfc58e9945580cce8b2bb
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Nov 10 14:40:09 2020 +0100

    x86/CPUID: also check leaf 7 max subleaf to be compatible
    
    Just like is done for basic and extended major leaves.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit f5cfa09856732b1d78ff6a21ca3dc33a010da951
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Nov 10 14:39:30 2020 +0100

    x86/CPUID: suppress IOMMU related hypervisor leaf data
    
    Now that the IOMMU for guests can't be enabled "on demand" anymore,
    there's also no reason to expose the related CPUID bit "just in case".
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit db1a9fdd554cb1d8a7099af7925318fc06c6875b
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Nov 10 14:39:03 2020 +0100

    x86/CPUID: don't use UB shift when library is built as 32-bit
    
    At least the insn emulator test harness will continue to be buildable
    (and ought to continue to be usable) also as a 32-bit binary. (Right now
    the CPU policy test harness is, too, but there it may be less relevant
    to keep it functional, just like e.g. we don't support fuzzing the insn
    emulator in 32-bit mode.) Hence the library code needs to cope with
    this.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit b5ad37f8e9284cc147218f7a5193d739ae7b956f
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Tue Nov 10 14:37:15 2020 +0100

    xen/evtchn: revert 52e1fc47abc3a0123
    
    With the event channel lock no longer disabling interrupts commit
    52e1fc47abc3a0123 ("evtchn/Flask: pre-allocate node on send path") can
    be reverted again.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 5f2df45ead7c1195142f68b7923047a1e9479d54
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Tue Nov 10 14:36:15 2020 +0100

    xen/evtchn: rework per event channel lock
    
    Currently the lock for a single event channel needs to be taken with
    interrupts off, which causes deadlocks in some cases.
    
    Rework the per event channel lock to be non-blocking for the case of
    sending an event and removing the need for disabling interrupts for
    taking the lock.
    
    The lock is needed for avoiding races between event channel state
    changes (creation, closing, binding) against normal operations (set
    pending, [un]masking, priority changes).
    
    Use a rwlock, but with some restrictions:
    
    - Changing the state of an event channel (creation, closing, binding)
      needs to use write_lock(), with ASSERT()ing that the lock is taken as
      writer only when the state of the event channel is either before or
      after the locked region appropriate (either free or unbound).
    
    - Sending an event needs to use read_trylock() mostly, in case of not
      obtaining the lock the operation is omitted. This is needed as
      sending an event can happen with interrupts off (at least in some
      cases).
    
    - Dumping the event channel state for debug purposes is using
      read_trylock(), too, in order to avoid blocking in case the lock is
      taken as writer for a long time.
    
    - All other cases can use read_lock().
    
    Fixes: e045199c7c9c54 ("evtchn: address races with evtchn_reset()")
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Julien Grall <jgrall@xxxxxxxxxx>
(qemu changes not included)