This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] [xen-unstable test] 6752: regressions - FAIL

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [xen-unstable test] 6752: regressions - FAIL
From: xen.org <ian.jackson@xxxxxxxxxxxxx>
Date: Tue, 5 Apr 2011 19:54:51 +0100
Cc: ian.jackson@xxxxxxxxxxxxx
Delivery-date: Tue, 05 Apr 2011 11:55:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
flight 6752 xen-unstable real [real]

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-xcpkern-i386-xl-credit2 11 guest-localmigrate   fail REGR. vs. 6751
 test-i386-xcpkern-i386-pair   8 xen-boot/dst_host          fail REGR. vs. 6751

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd  8 guest-saverestore            fail   never pass
 test-amd64-i386-rhel6hvm-intel  8 guest-saverestore            fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-xcpkern-i386-rhel6hvm-amd  8 guest-saverestore      fail never pass
 test-amd64-xcpkern-i386-rhel6hvm-intel  8 guest-saverestore    fail never pass
 test-amd64-xcpkern-i386-win  16 leak-check/check             fail   never pass
 test-amd64-xcpkern-i386-xl-win 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-xcpkern-i386-win   16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  fbfee2a01a91
baseline version:
 xen                  967e1925775c

People who touched revisions under test:
  Jan Beulich <jbeulich@xxxxxxxxxx>
  Machon Gregory <mbgrego@xxxxxxxxxxxxxx>

 build-i386-xcpkern                                           pass     
 build-amd64                                                  pass     
 build-i386                                                   pass     
 build-amd64-oldkern                                          pass     
 build-i386-oldkern                                           pass     
 build-amd64-pvops                                            pass     
 build-i386-pvops                                             pass     
 test-amd64-amd64-xl                                          pass     
 test-amd64-i386-xl                                           pass     
 test-i386-i386-xl                                            pass     
 test-amd64-xcpkern-i386-xl                                   pass     
 test-i386-xcpkern-i386-xl                                    pass     
 test-amd64-i386-rhel6hvm-amd                                 fail     
 test-amd64-xcpkern-i386-rhel6hvm-amd                         fail     
 test-amd64-i386-xl-credit2                                   pass     
 test-amd64-xcpkern-i386-xl-credit2                           fail     
 test-amd64-i386-rhel6hvm-intel                               fail     
 test-amd64-xcpkern-i386-rhel6hvm-intel                       fail     
 test-amd64-i386-xl-multivcpu                                 pass     
 test-amd64-xcpkern-i386-xl-multivcpu                         pass     
 test-amd64-amd64-pair                                        pass     
 test-amd64-i386-pair                                         pass     
 test-i386-i386-pair                                          pass     
 test-amd64-xcpkern-i386-pair                                 pass     
 test-i386-xcpkern-i386-pair                                  fail     
 test-amd64-amd64-pv                                          pass     
 test-amd64-i386-pv                                           pass     
 test-i386-i386-pv                                            pass     
 test-amd64-xcpkern-i386-pv                                   pass     
 test-i386-xcpkern-i386-pv                                    pass     
 test-amd64-i386-win-vcpus1                                   fail     
 test-amd64-i386-xl-win-vcpus1                                fail     
 test-amd64-amd64-win                                         fail     
 test-amd64-i386-win                                          fail     
 test-i386-i386-win                                           fail     
 test-amd64-xcpkern-i386-win                                  fail     
 test-i386-xcpkern-i386-win                                   fail     
 test-amd64-amd64-xl-win                                      fail     
 test-i386-i386-xl-win                                        fail     
 test-amd64-xcpkern-i386-xl-win                               fail     

sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at

Test harness code can be found at

Not pushing.

changeset:   23146:fbfee2a01a91
tag:         tip
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Tue Apr 05 13:05:05 2011 +0100
    passthrough: use domain pirq as index of struct hvm_irq_dpci's hvm_timer 
    Since d->nr_pirqs is guaranteed to be not larger than nr_irqs,
    indexing arrays by the former ought to be preferred. In the case
    given, the indices so far had to be computed specially in a number of
    cases, whereas the indexes use now are all readily available.
    This opens the possibility to fold the ->mirq[] and ->hvm_timer[]
    members of struct hvm_irq_dpci into a single array, possibly with some
    members overlayed in a union to reduce size (see
    Such space saving wouldn't, however, suffice to generally get the
    respective allocation sizes here to below PAGE_SIZE, not even when
    converting the array of structures into an array of pointers to
    structures. Whether a multi-level lookup mechanism would make sense
    here is questionable, as it can be expected that for other than Dom0
    (which isn't hvm, and hence shouldn't use these data structures - see
    only very few entries would commonly be used here. An obvious
    alternative would be to use rb or radix trees (both currently only
    used in tmem).
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset:   23145:4fe0442aa5b7
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Tue Apr 05 13:03:29 2011 +0100
    x86: introduce alloc_vcpu_guest_context()
    This is necessary because on x86-64 struct vcpu_guest_context is
    larger than PAGE_SIZE, and hence not suitable for a general purpose
    runtime allocation. On x86-32, FIX_PAE_HIGHMEM_* fixmap entries are
    being re-used, whiule on x86-64 new per-CPU fixmap entries get
    introduced.  The implication of using per-CPU fixmaps is that these
    allocations have to happen from non-preemptable hypercall context
    (which they all do).
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset:   23144:37c4f7d492a4
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Tue Apr 05 13:02:57 2011 +0100
    x86: split struct domain
    This is accomplished by converting a couple of embedded arrays (in one
    case a structure containing an array) into separately allocated
    pointers, and (just as for struct arch_vcpu in a prior patch)
    overlaying some PV-only fields with HVM-only ones.
    One particularly noteworthy change in the opposite direction is that
    of PITState - this field so far lived in the HVM-only portion, but is
    being used by PV guests too, and hence needed to be moved out of
    struct hvm_domain.
    The change to XENMEM_set_memory_map (and hence libxl__build_pre() and
    the movement of the E820 related pieces to struct pv_domain) are
    subject to a positive response to a query sent to xen-devel regarding
    the need for this to happen for HVM guests (see
    The protection of arch.hvm_domain.irq.dpci accesses by is_hvm_domain()
    is subject to confirmation that the field is used for HVM guests only
    In the absence of any reply to these queries, and given the early
    state of 4.2 development, I think it should be acceptable to take the
    risk of having to later undo/redo some of this.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset:   23143:2f7f24fe5924
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Tue Apr 05 13:02:00 2011 +0100
    x86: move pv-only members of struct vcpu to struct pv_vcpu
    ... thus further shrinking overall size of struct arch_vcpu.
    This has a minor effect on XEN_DOMCTL_{get,set}_ext_vcpucontext - for
    HVM guests, some meaningless fields will no longer get stored or
    retrieved: reads will now return zero, and writes are required to be
    (mostly) zero (the same as was already done on x86-32).
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset:   23142:f5e8d152a565
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Tue Apr 05 13:01:25 2011 +0100
    x86: split struct vcpu
    This is accomplished by splitting the guest_context member, which by
    itself is larger than a page on x86-64. Quite a number of fields of
    this structure is completely meaningless for HVM guests, and thus a
    new struct pv_vcpu gets introduced, which is being overlaid with
    struct hvm_vcpu in struct arch_vcpu. The one member that is mostly
    responsible for the large size is trap_ctxt, which now gets allocated
    separately (unless fitting on the same page as struct arch_vcpu, as is
    currently the case for x86-32), and only for non-hvm, non-idle
    This change pointed out a latent problem in arch_set_info_guest(),
    which is permitted to be called on already initialized vCPU-s, but
    so far copied the new state into struct arch_vcpu without (in this
    case) actually going through all the necessary accounting/validation
    steps. The logic gets changed so that the pieces that bypass
    will at least be verified to be no different from the currently active
    bits, and the whole change will fail in case they are. The logic does
    *not* get adjusted here to do full error recovery, that is, partially
    modified state continues to not get unrolled in case of failure.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset:   23141:c2d7a9fd7364
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Tue Apr 05 13:00:54 2011 +0100
    Remove direct cpumask_t members from struct vcpu and struct domain
    The CPU masks embedded in these structures prevent NR_CPUS-independent
    sizing of these structures.
    Basic concept (in xen/include/cpumask.h) taken from recent Linux.
    For scalability purposes, many other uses of cpumask_t should be
    replaced by cpumask_var_t, particularly local variables of functions.
    This implies that no functions should have by-value cpumask_t
    parameters, and that the whole old cpumask interface (cpus_...())
    should go away in favor of the new (cpumask_...()) one.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset:   23140:967e1925775c
user:        Machon Gregory <mbgrego@xxxxxxxxxxxxxx>
date:        Mon Apr 04 15:54:45 2011 +0100
    xsm: Error code consistency
    Signed-off-by: Machon Gregory <mbgrego@xxxxxxxxxxxxxx>
(qemu changes not included)

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [xen-unstable test] 6752: regressions - FAIL, xen . org <=