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

[xen-4.9-testing test] 114070: regressions - FAIL



flight 114070 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114070/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
113367
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
113367
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
113367

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail REGR. vs. 113367
 test-armhf-armhf-xl-rtds     12 guest-start              fail REGR. vs. 113367

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop            fail like 113367
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-check        fail  never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install        fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install        fail never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check    fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm      13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check    fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check        fail  never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore       fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore       fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      13 saverestore-support-check    fail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-install        fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install        fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install         fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install         fail never pass

version targeted for testing:
 xen                  1cdcb36701fd22aec1106b5973d027f742e4f1dd
baseline version:
 xen                  2cc3d32f40c71cb242477a3f8938074d4fc36829

Last test of basis   113367  2017-09-12 13:11:34 Z   24 days
Testing same since   114070  2017-10-06 13:15:32 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
  Chao Gao <chao.gao@xxxxxxxxx>
  Crawford, Eric R <Eric.R.Crawford@xxxxxxxxx>
  David Woodhouse <dwmw@xxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Julien Grall <julien.grall@xxxxxxx>
  Paul Durrant <paul.durrant@xxxxxxxxxx>
  Stefano Stabellini <sstabellini@xxxxxxxxxx>
  Xiong Zhang <xiong.y.zhang@xxxxxxxxx>

jobs:
 build-amd64-xsm                                              pass    
 build-armhf-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 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-rumprun                                          pass    
 build-i386-rumprun                                           pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm                pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm                pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm                 pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-armhf-armhf-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-armhf-armhf-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-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-rumprun-amd64                               fail    
 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-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-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-rumprun-i386                                 pass    
 test-amd64-amd64-xl-qemut-win10-i386                         fail    
 test-amd64-i386-xl-qemut-win10-i386                          fail    
 test-amd64-amd64-xl-qemuu-win10-i386                         fail    
 test-amd64-i386-xl-qemuu-win10-i386                          fail    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 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-amd64-i386-libvirt-qcow2                                pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     fail    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      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 1cdcb36701fd22aec1106b5973d027f742e4f1dd
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Fri Oct 6 14:59:38 2017 +0200

    xen/arm: Correctly report the memory region in the dummy NUMA helpers
    
    NUMA is currently not supported on Arm. Because common code is
    NUMA-aware, dummy helpers are instead provided to expose a single node.
    
    Those helpers are for instance used to know the region to scrub.
    
    However the memory region is not reported correctly. Indeed, the
    frametable may not be at the beginning of the memory and there might be
    multiple memory banks. This will lead to not scrub some part of the
    memory.
    
    The memory information can be found using:
        * first_valid_mfn as the start of the memory
        * max_page - first_valid_mfn as the spanned pages
    
    Note that first_valid_mfn is now been exported. The prototype has been
    added in asm-arm/numa.h and not in a common header because I would
    expect the variable to become static once NUMA is fully supported on
    Arm.
    
    This is XSA-245.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Signed-off-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
    master commit: 5414ba7f5e1ffc88ed2758b1e1b14bbfd3536a61
    master date: 2017-09-29 13:23:11 -0700

commit 84c039eaf73a0ffd05a04330bb2763b0a2291609
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Fri Oct 6 14:59:00 2017 +0200

    xen/page_alloc: Cover memory unreserved after boot in first_valid_mfn
    
    On Arm, some regions (e.g Initramfs, Dom0 Kernel...) are marked as
    reserved until the hardware domain is built and they are copied into its
    memory. Therefore, they will not be added in the boot allocator via
    init_boot_pages.
    
    Instead, init_xenheap_pages will be called once the region are not used
    anymore.
    
    Update first_valid_mfn in both init_heap_pages and init_boot_pages
    (already exist) to cover all the cases.
    
    This is XSA-245.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    [Adjust comment, added locking around first_valid_mfn update]
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
    master commit: ec6d9023e1f54cdccbf2e4c63cf947f1be2b1e8e
    master date: 2017-09-29 13:22:52 -0700

commit b244ac995c7c1ef79fc0e7cfbad146ec8f0445f3
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Oct 6 14:57:55 2017 +0200

    x86/HVM: correct repeat count update in linear->phys translation
    
    For the insn emulator's fallback logic in REP INS/OUTS handling
    to work correctly, *reps must not be set to zero when returning
    X86EMUL_UNHANDLEABLE.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    master commit: 49160d205236d8e36d27d40b6bf69b9b75f2c333
    master date: 2017-09-08 16:23:46 +0200

commit 612044a8097c303de522a034d0f03a07a7fed742
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Oct 6 14:57:20 2017 +0200

    x86: introduce and use setup_force_cpu_cap()
    
    For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd
    need to clone the respective hack used for CPUID_FAULTING. Introduce an
    inverse of setup_clear_cpu_cap() instead, but let clearing of features
    overrule forced setting of them.
    
    XEN_SMAP being wrong post-boot is a problem specifically for live
    patching, as a live patch may need alternative instruction patching
    keyed off of that feature flag.
    
    Reported-by: Sarah Newman <security@xxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: 0829a6bdbdc6b79990bd0668e847275b6a2717e5
    master date: 2017-09-06 12:32:00 +0200

commit e8fd37235064347cfd8c089b48e23280551d35a3
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Oct 6 14:56:47 2017 +0200

    x86emul: correct VEX.L handling for VCVT{,T}S{S,D}2SI
    
    Recent changes to the SDM (and XED) have made clear that older hardware
    raising #UD when the bit is set was really an erratum. Generalize the
    so far AMD-only override.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: a6488965ca3ec30f2e0b7022b539bba78c2aeede
    master date: 2017-09-05 17:32:05 +0200

commit a568e25a38e55d15ca8b003e281ce9bc28fcee24
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Oct 6 14:56:11 2017 +0200

    x86emul: correct VEX.W handling for non-64-bit VPINSRD
    
    Going though the XED commits from the last couple of months made me
    notice that VPINSRD, other than VPEXTRD, does not clear VEX.W for non-
    64-bit modes, leading to an insertion of stray 32-bits of zero in case
    the original instruction had the bit set.
    
    Also remove a pointless fall-through in VPEXTRW handling, bringing
    things in line with VPINSRW.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: 9c2babd05a213f8802e3cc1c64a2af932b5cbd7d
    master date: 2017-09-05 17:31:01 +0200

commit 8fef83e60bc3036c8bf4d37d59114c766610be7c
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Fri Oct 6 14:55:33 2017 +0200

    x86/emul: Fix the handling of unimplemented Grp7 instructions
    
    Grp7 is abnormally complicated to decode, even by x86's standards, with
    {s,l}msw being the problematic cases.
    
    Previously, any value which fell through the first switch statement (looking
    for instructions with entirely implicit operands) would be interpreted by 
the
    second switch statement (handling instructions with memory operands).
    
    Unimplemented instructions would then hit the #UD case for having a 
non-memory
    operand, rather than taking the cannot_emulate path.
    
    Consolidate the two switch statements into a single one, using ranges to 
cover
    the instructions with memory operands.
    
    Reported-by: Petre Pircalabu <ppircalabu@xxxxxxxxxxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <JBeulich@xxxxxxxx>
    master commit: 4d3f0fde471e7588ce512eaff1abdab209d8cd4b
    master date: 2017-09-05 12:58:47 +0100

commit 478e40cd6447b343a47ce99b8401f7dece770799
Author: Chao Gao <chao.gao@xxxxxxxxx>
Date:   Fri Oct 6 14:54:51 2017 +0200

    VT-d: use correct BDF for VF to search VT-d unit
    
    When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function'
    are under the scope of the same VT-d unit as the 'Physical Function'.
    A 'Physical Function' can be a 'Traditional Function' or an ARI
    'Extended Function'. And furthermore, 'Extended Functions' on an
    endpoint are under the scope of the same VT-d unit as the 'Traditional
    Functions' on the endpoint. To search VT-d unit for a VF, if its PF
    isn't an extended function, the BDF of PF should be used. Otherwise
    the BDF of a traditional function in the same device with the PF
    should be used.
    
    Current code uses PCI_SLOT() to recognize an ARI 'Extended Funcion'.
    But it is conceptually wrong w/o checking whether PF is an extended
    function and would lead to match VFs of a RC integrated PF to a wrong
    VT-d unit.
    
    This patch overrides VF 'is_extfn' field and uses this field to
    indicate whether the PF of this VF is an extended function. The field
    helps to use correct BDF to search VT-d unit.
    
    Reported-by: Crawford, Eric R <Eric.R.Crawford@xxxxxxxxx>
    Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
    Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    Tested-by: Crawford, Eric R <Eric.R.Crawford@xxxxxxxxx>
    master commit: c286af54c7177c14180121b422d8df7281e547cb
    master date: 2017-09-01 11:02:23 +0200

commit 22ea7316e5440b16965471b5c1026f178ee9683e
Author: Xiong Zhang <xiong.y.zhang@xxxxxxxxx>
Date:   Fri Oct 6 14:54:24 2017 +0200

    hvmloader: use base instead of pci_mem_start for find_next_rmrr()
    
    find_next_rmrr(base) is used to find the lowest RMRR ending above base
    but below 4G. Current method couldn't cover the following situation:
    a. two rmrr exist, small gap between them
    b. pci_mem_start and mem_resource.base is below the first rmrr.base
    c. find_next_rmrr(pci_mem_start) will find the first rmrr
    d. After aligning mem_resource.base to bar size,
       first_rmrr.end < new_base < second_rmrr.base and
       new_base + bar_sz > second_rmrr.base.
       So the new bar will overlap with the second rmrr and doesn't overlap
    with the first rmrr.
    But the next_rmrr point to the first rmrr, then check_overlap() couldn't
    find the overlap. Finally assign a wrong address to bar.
    
    This patch using aligned new base to find the next rmrr, could fix the
    above case and find all the overlapped rmrr with new base.
    
    Signed-off-by: Xiong Zhang <xiong.y.zhang@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    master commit: ecc607b1851bc27140090da4d6124fd00090ec2b
    master date: 2017-08-28 10:51:24 +0200

commit e7703a2e86f9002b414b6b6138c2f649af3224bc
Author: David Woodhouse <dwmw@xxxxxxxxxxxx>
Date:   Fri Oct 6 14:53:51 2017 +0200

    x86/efi: don't write relocations in efi_arch_relocate_image() first pass
    
    The function is invoked with delta=0 before ExitBootServices() is called,
    as a dummy run purely to validate that all the relocations can be handled.
    This allows us to exit gracefully with an error message.
    
    However, we have relocations in read-only sections such as .rodata and
    .init.te(xt). Recent versions of UEFI will actually make those sections
    read-only, which will cause a fault. This functionaity was added in
    EDK2 commit d0e92aad4 ("MdeModulePkg/DxeCore: Add UEFI image protection.")
    
    It's OK to actually make the changes in the later pass because UEFI will
    tear down the protection when ExitBootServices() is called, because it
    knows we're going to need to do this kind of thing.
    
    Reported-by: Jan Beulich <jbeulich@xxxxxxxx>
    Signed-off-by: David Woodhouse <dwmw@xxxxxxxxxxxx>
    master commit: 34828425d36b560adfe96430b9b83dfb0f66f2a8
    master date: 2017-08-25 14:07:40 +0200

commit 91ded3b748a6cbfa6a53a8e02df985c3f9d90ad6
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Oct 6 14:52:48 2017 +0200

    x86: check for allocation errors in modify_xen_mappings()
    
    Reported-by: Julien Grall <julien.grall@xxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: e466ec4f51d38a2c9d02bf9f3d5e43e47db2d66b
    master date: 2017-08-25 14:03:47 +0200
(qemu changes not included)

_______________________________________________
osstest-output mailing list
osstest-output@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/osstest-output

 


Rackspace

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