[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [xen-4.5-testing test] 93928: regressions - FAIL

flight 93928 xen-4.5-testing real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt     14 guest-saverestore         fail REGR. vs. 92345
 test-armhf-armhf-xl          15 guest-start/debian.repeat fail REGR. vs. 92345
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds     11 guest-start                  fail   like 92182
 test-amd64-i386-libvirt      14 guest-saverestore            fail   like 92237
 test-amd64-amd64-xl-rtds      6 xen-boot                     fail   like 92345
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate     fail like 92345
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop              fail like 92345
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop             fail like 92345

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start                  fail  never pass
 test-amd64-i386-libvirt      12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start                  fail   never pass
 test-armhf-armhf-xl          13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-check        fail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 guest-saverestore            fail   never pass
 test-armhf-armhf-libvirt     12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      10 guest-start                  fail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start                  fail never pass
 test-armhf-armhf-libvirt-raw 10 guest-start                  fail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-check    fail never pass

version targeted for testing:
 xen                  2bc9bd9483b254a80b7f83408f45aa1c6ef17ef3
baseline version:
 xen                  c70ab649fcde2f0c3d750d35f5e2b77d619ba80b

Last test of basis    92345  2016-04-22 10:56:14 Z   18 days
Failing since         93905  2016-05-09 11:39:53 Z    1 days    2 attempts
Testing same since    93928  2016-05-09 20:11:22 Z    0 days    1 attempts

People who touched revisions under test:
  David Vrabel <david.vrabel@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Juergen Gross <jgross@xxxxxxxx>
  Mike Meyer <mike.meyer@xxxxxxxxxxxx>
  Mike Meyer Mon Apr 4 15:02:59 2016 +0200 <mike.meyer@xxxxxxxxxxxx>
  Olaf Hering <olaf@xxxxxxxxx>
  Roger Pau Monne <roger.pau@xxxxxxxxxx>
  Roger Pau Monné <roger.pau@xxxxxxxxxx>
  Stefano Stabellini <sstabellini@xxxxxxxxxx>
  Tim Deegan <tim@xxxxxxx>
  Wei Liu <wei.liu2@xxxxxxxxxx>

 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               fail    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     pass    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           pass    
 test-amd64-i386-xl-qemut-winxpsp3                            pass    
 test-amd64-amd64-xl-qemuu-winxpsp3                           pass    
 test-amd64-i386-xl-qemuu-winxpsp3                            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

Explanation of these reports, and of osstest in general, is at

Test harness code can be found at

Not pushing.

commit 2bc9bd9483b254a80b7f83408f45aa1c6ef17ef3
Author: Roger Pau Monne <roger.pau@xxxxxxxxxx>
Date:   Tue Apr 26 12:07:49 2016 +0200

    libxc: fix usage of uninitialized variable
    *size should be used instead, because it contains the size of the buffer in
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    (cherry picked from commit 13b3d3505c3ea9a881e9733be8b47f7b17a5bdde)
    (cherry picked from commit 39546d1360d954c2d0e2ff71dc74851e7081f61f)

commit 350eb394166d18a754b4954723c8373dfe652520
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Wed Mar 30 17:33:29 2016 +0200

    libxl: handle error from libxl__need_xenpv_qemu() correctly
    In case libxl__need_xenpv_qemu() returns an error let domain creation
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    (cherry picked from commit 1a7ac00fa69de7431349d9583a2b8ed724711360)
    (cherry picked from commit e7e194074adf896c226caaa778f6f4c8abfb1023)

commit 065b1347b0902fd68291ddc593a0055259793383
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Mon May 9 13:16:10 2016 +0200

    x86/shadow: account for ioreq server pages before complaining about not 
found mapping
    prepare_ring_for_helper(), just like share_xen_page_with_guest(),
    takes a write reference on the page, and hence should similarly be
    accounted for when determining whether to log a complaint.
    This requires using recursive locking for the ioreq server lock, as the
    offending invocation of sh_remove_all_mappings() is down the call stack
    from hvm_set_ioreq_server_state(). (While not strictly needed to be
    done in all other instances too, convert all of them for consistency.)
    At once improve the usefulness of the shadow error message: Log all
    values involved in triggering it as well as the GFN (to aid
    understanding which guest page it is that there is a problem with - in
    cases like the one here the GFN is invariant across invocations, while
    the MFN obviously can [and will] vary).
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Tim Deegan <tim@xxxxxxx>
    master commit: 77eb5dbeff78bbe549793325520f59ab46a187f8
    master date: 2016-05-02 09:20:17 +0200

commit f9cc40e87768ccb80bd10a106e300848ac532067
Author: Jan Beulich <JBeulich@xxxxxxxx>
Date:   Mon May 9 13:15:14 2016 +0200

    x86/time: fix gtime_to_gtsc for vtsc=1 PV guests
    For vtsc=1 PV guests, rdtsc is trapped and calculated from get_s_time()
    using gtime_to_gtsc. Similarly the tsc_timestamp, part of struct
    vcpu_time_info, is calculated from stime_local_stamp using
    However gtime_to_gtsc can return 0, if time < vtsc_offset, which can
    actually happen when gtime_to_gtsc is called passing stime_local_stamp
    (the caller function is __update_vcpu_system_time).
    In that case the pvclock protocol doesn't work properly and the guest is
    unable to calculate the system time correctly. As a consequence when the
    guest tries to set a timer event (for example calling the
    VCPUOP_set_singleshot_timer hypercall), the event will be in the past
    causing Linux to hang.
    The purpose of the pvclock protocol is to allow the guest to calculate
    the system_time in nanosec correctly. The guest calculates as follow:
      from_vtsc_scale(rdtsc - vcpu_time_info.tsc_timestamp) + 
    Given that with vtsc=1:
      rdtsc = to_vtsc_scale(NOW() - vtsc_offset)
      vcpu_time_info.tsc_timestamp = to_vtsc_scale(vcpu_time_info.system_time - 
    The expression evaluates to NOW(), which is what we want.  However when
    stime_local_stamp < vtsc_offset, vcpu_time_info.tsc_timestamp is
    actually 0. As a consequence the calculated overall system_time is not
    This patch fixes the issue by letting gtime_to_gtsc return a negative
    integer in the form of a wrapped around unsigned integer, thus when the
    guest subtracts vcpu_time_info.tsc_timestamp from rdtsc will calculate
    the right value.
    Signed-off-by: Jan Beulich <JBeulich@xxxxxxxx>
    Signed-off-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: d22c9bf7c3067b17cbd9cdfd8b81941dd6fb8d77
    master date: 2016-04-28 15:06:56 +0200

commit becb125a25859f42ec40a156ca1aa138f5d6fdd7
Author: Mike Meyer Mon Apr 4 15:02:59 2016 +0200 <mike.meyer@xxxxxxxxxxxx>
Date:   Mon Apr 4 15:02:59 2016 +0200

    unmodified_drivers: enable use of register_oldmem_pfn_is_ram() API
    Git: a0f793d82d5ec2d0b67c57d7130bf01c91396c60
    During the investigation of very slow dump times of guest images in
    Amazon EC2 instance, it was discovered that the
    register_oldmem_pfn_is_ram() API implemented by the upstream kernel
    commit 997c136f518c5debd63847e78e2a8694f56dcf90:
            fs/proc/vmcore.c: add hook to read_from_oldmem() to check
                               for non-ram pages
    was not being called.  This was due to the PV driver with the call
    to register_oldmem_pfn_is_ram() API was not including the
    kernel header file that is used to communicate support of the API in the
    kernel.  Fix the issue by including the required header file.
    Signed-off-by: Mike Meyer <mike.meyer@xxxxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Olaf Hering <olaf@xxxxxxxxx>

commit 0aabc2855c9e10b61ceb75a6b25ecc6d467e99e5
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Mon May 9 13:05:42 2016 +0200

    x86/HVM: fix forwarding of internally cached requests
    Forwarding entire batches to the device model when an individual
    iteration of them got rejected by internal device emulation handlers
    with X86EMUL_UNHANDLEABLE is wrong: The device model would then handle
    all iterations, without the internal handler getting to see any past
    the one it returned failure for. This causes misbehavior in at least
    the MSI-X and VGA code, which want to see all such requests for
    internal tracking/caching purposes. But note that this does not apply
    to buffered I/O requests.
    This in turn means that the condition in hvm_process_io_intercept() of
    when to crash the domain was wrong: Since X86EMUL_UNHANDLEABLE can
    validly be returned by the individual device handlers, we mustn't
    blindly crash the domain if such occurs on other than the initial
    iteration. Instead we need to distinguish hvm_copy_*_guest_phys()
    failures from device specific ones, and then the former need to always
    be fatal to the domain (i.e. also on the first iteration), since
    otherwise we again would end up forwarding a request to qemu which the
    internal handler didn't get to see.
    The adjustment should be okay even for stdvga's MMIO handling:
    - if it is not caching then the accept function would have failed so we
      won't get into hvm_process_io_intercept(),
    - if it issued the buffered ioreq then we only get to the p->count
      reduction if hvm_send_ioreq() actually encountered an error (in which
      we don't care about the request getting split up).
    Also commit 4faffc41d ("x86/hvm: limit reps to avoid the need to handle
    retry") went too far in removing code from hvm_process_io_intercept():
    When there were successfully handled iterations, the function should
    continue to return success with a clipped repeat count.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    x86/HVM: fix forwarding of internally cached requests (part 2)
    Commit 96ae556569 ("x86/HVM: fix forwarding of internally cached
    requests") wasn't quite complete: hvmemul_do_io() also needs to
    propagate up the clipped count. (I really should have re-tested the
    forward port resulting in the earlier change, instead of relying on the
    testing done on the older version of Xen which the fix was first needed
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: 96ae556569b8eaedc0bb242932842c3277b515d8
    master date: 2016-03-31 14:52:04 +0200
    master commit: 670ee15ac1e3de7c15381fdaab0e531489b48939
    master date: 2016-04-28 15:09:26 +0200

commit 12acca51313d3582968287e2dd3d7498cb02a7ce
Author: David Vrabel <david.vrabel@xxxxxxxxxx>
Date:   Mon May 9 13:05:13 2016 +0200

    x86/fpu: improve check for XSAVE* not writing FIP/FDP fields
    The hardware may not write the FIP/FDP fields with a XSAVE*
    instruction.  e.g., with XSAVEOPT/XSAVES if the state hasn't changed
    or on AMD CPUs when a floating point exception is not pending.  We
    need to identify this case so we can correctly apply the check for
    whether to save/restore FCS/FDS.
    By poisoning FIP in the saved state we can check if the hardware
    writes to this field.  The poison value is both: a) non-canonical; and
    b) random with a vanishingly small probability of matching a value
    written by the hardware (1 / (2^63) = 10^-19).
    The poison value is fixed and thus knowable by a guest (or guest
    userspace).  This could allow the guest to cause Xen to incorrectly
    detect that the field has not been written.  But: a) this requires the
    FIP register to be a full 64 bits internally which is not the case for
    all current AMD and Intel CPUs; and b) this only allows the guest (or
    a guest userspace process) to corrupt its own state (i.e., it cannot
    affect the state of another guest or another user space process).
    This results in smaller code with fewer branches and is more
    Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
    Intel confirmed that 64-bit {F,}XRSTOR sign-extend FIP from bit 47.
    While leaving the description above intact, modify the code comment
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    master commit: e869abd77aa32fb0a5212d34ae954e4dbcb8f7a5
    master date: 2016-03-18 09:49:01 +0100

commit 9945f6230f83a3869526bec6e5eb865098e79c05
Author: David Vrabel <david.vrabel@xxxxxxxxxx>
Date:   Mon May 9 13:04:26 2016 +0200

    x86/hvm: add HVM_PARAM_X87_FIP_WIDTH
    The HVM parameter HVM_PARAM_X87_FIP_WIDTH to allow tools and the guest
    to adjust the width of the FIP/FDP registers to be saved/restored by
    the hypervisor.  This is in case the hypervisor hueristics do not do
    the right thing.
    Add this parameter to the set saved during domain save/migrate.
    Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    master commit: 5d768fb1f3f7b011e7b6e75909c7f4841730de60
    master date: 2016-02-26 12:30:11 +0100

commit 38eee32060212bf6fe363e334e340465ec0a870a
Author: David Vrabel <david.vrabel@xxxxxxxxxx>
Date:   Mon May 9 13:03:15 2016 +0200

    x86/fpu: add a per-domain field to set the width of FIP/FDP
    The x86 architecture allows either: a) the 64-bit FIP/FDP registers to
    be restored (clearing FCS and FDS); or b) the 32-bit FIP/FDP and
    FCS/FDS registers to be restored (clearing the upper 32-bits).
    Add a per-domain field to indicate which of these options a guest
    needs.  The options are: 8, 4 or 0.  Where 0 indicates that the
    hypervisor should automatically guess the FIP width by checking the
    value of FIP/FDP when saving the state (this is the existing
    The FIP width is initially automatic but is set explicitly in the
    following cases:
    - 32-bit PV guest: 4
    - Newer CPUs that do not save FCS/FDS: 8
    The x87_fip_width field is placed into an existing 1 byte hole in
    struct arch_domain.
    Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
    Fix build.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    master commit: 879b44b041f26de35e4b527bf0f3c361eb52bd82
    master date: 2016-02-26 12:29:21 +0100
(qemu changes not included)

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.