[Xen-devel] [xen-unstable-smoke test] 104203: regressions - FAIL

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           6 xen-boot                 fail REGR. vs. 104195

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  5ad98e3c7fa92f46d77a788e1109b7d282bd1256
baseline version:
 xen                  c33b5f013db3460c07c017dea45a1c010c3dacc0

Last test of basis   104195  2017-01-17 00:01:46 Z    0 days
Testing same since   104203  2017-01-17 10:01:46 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@xxxxxxxx>

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          fail    
 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


Not pushing.

------------------------------------------------------------
commit 5ad98e3c7fa92f46d77a788e1109b7d282bd1256
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Jan 17 10:33:25 2017 +0100

    x86emul: support ADCX/ADOX
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit f88e810cc130d919dc69dfb1e632a602c9d10823
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Jan 17 10:32:54 2017 +0100

    x86emul: support POPCNT
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 89c76ee7f60777b81c8fd0475a6af7c84e72a791
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Jan 17 10:32:25 2017 +0100

    x86emul: VEX.B is ignored in compatibility mode
    
    While VEX.R and VEX.X are guaranteed to be 1 in compatibility mode
    (and hence a respective mode_64bit() check can be dropped), VEX.B can
    be encoded as zero, but would be ignored by the processor. Since we
    emulate instructions in 64-bit mode (except possibly in the test
    harness), we need to force the bit to 1 in order to not act on the
    wrong {X,Y,Z}MM register (which has no bad effect on 32-bit test
    harness builds, as there the bit would again be ignored by the
    hardware, and would by default be expected to be 1 anyway).
    
    We must not, however, fiddle with the high bit of VEX.VVVV in the
    decode phase, as that would undermine the checking of instructions
    requiring the field to be all ones independent of mode. This is
    being enforced in copy_REX_VEX() instead.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 48965ec2c624d15b0e10ca21da379f45c77f35c4
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Jan 17 10:31:39 2017 +0100

    x86emul: suppress memory writes after faulting FPU insns
    
    FPU insns writing to memory must not touch memory if they latch #MF (to
    be delivered on the next waiting FPU insn). Note that inspecting FSW.ES
    needs to be avoided for all FNST* insns, as they don't raise exceptions
    themselves, but may instead be invoked with the bit already set.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel