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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 20 guest-start/debianhvm.repeat fail 
REGR. vs. 180283

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                  65c4e7472cafb60f478e7a5f358ee1eeac28b5a8
baseline version:
 xen                  5eb6bd7454e253f4907dbeb7aa982967b21698bc

Last test of basis   180283  2023-04-17 13:02:10 Z    0 days
Testing same since   180286  2023-04-17 17:03:22 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  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-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 65c4e7472cafb60f478e7a5f358ee1eeac28b5a8
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Mon Apr 17 18:11:45 2023 +0200

    x86emul: support AVX-NE-CONVERT insns
    
    Matching what was done earlier, explicit tests are added only for
    irregular insn / memory access patterns.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 842acaa743a503726d6c4d77a7982cc64f07c4bf
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Mon Apr 17 18:11:06 2023 +0200

    x86emul: support AVX-VNNI-INT8
    
    These are close relatives of the AVX-VNNI ISA extension. Since the insns
    here and in particular their memory access patterns follow the usual
    scheme (and especially the byte variants of AVX-VNNI), I didn't think it
    was necessary to add a contrived test specifically for them.
    
    While making the addition also re-wire AVX-VNNI's handling to
    simd_0f_ymm: There's no reason to check the AVX feature alongside the
    one actually of interest (there are a few features where two checks are
    actually necessary, e.g. GFNI+AVX, but this isn't the case here).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit da232f1f1118e8c8fad520dedee312005c2984fb
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Mon Apr 17 18:10:14 2023 +0200

    x86emul: support AVX-IFMA insns
    
    As in a few cases before (in particular: AVX512_IFMA), since the insns
    here and in particular their memory access patterns follow the usual
    scheme, I didn't think it was necessary to add a contrived test
    specifically for them.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
(qemu changes not included)