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

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



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt     15 guest-saverestore        fail REGR. vs. 115490
 test-amd64-amd64-xl-qemuu-debianhvm-i386 13 guest-saverestore fail REGR. vs. 
115490

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 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

version targeted for testing:
 xen                  29028ed8db226ad3b7bc576c1e8891983acaa3ff
baseline version:
 xen                  ff93dc55431517ed29c70dbff6721c6b0803acf9

Last test of basis   115490  2017-11-02 17:01:26 Z    0 days
Testing same since   115497  2017-11-02 20:01:37 Z    0 days    6 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Julien Grall <julien.grall@xxxxxxx>
  Wei Liu <wei.liu2@xxxxxxxxxx>

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386                     fail    
 test-amd64-amd64-libvirt                                     fail    


------------------------------------------------------------
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 29028ed8db226ad3b7bc576c1e8891983acaa3ff
Merge: 9ff6dbf ff93dc5
Author: Wei Liu <wei.liu2@xxxxxxxxxx>
Date:   Thu Nov 2 17:07:58 2017 +0000

    Merge remote-tracking branch 'origin/staging' into staging

commit 9ff6dbfa7576cc1c5d6f9a3c59c69a8503e36f11
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Oct 12 20:19:09 2017 +0100

    tools/dombuilder: Prevent failures of xc_dom_gnttab_init()
    
    Recent changes in grant table configuration have caused calls to
    xc_dom_gnttab_init() to fail if not proceeded with a call to
    xc_domain_set_gnttab_limits().  This is backwards from the point of view of
    3rd party dombuilder users.
    
    Add max_{grant,maptrack}_frames parameters to struct xc_dom_image, and 
require
    them to be set by callers using xc_dom_gnttab_init().  Libxl, which uses
    xc_dom_gnttab_init() itself is updated appropriately.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Tested-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Juergen Gross <jgross@xxxxxxxx>
    Release-acked-by: Julien Grall <julien.grall@xxxxxxxxxx>

commit 87b0ae7e8277d2fa13486ce2e11a941e55f8df40
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Oct 12 20:19:08 2017 +0100

    tools/dombuilder: Fix asymmetry when setting up console and xenstore rings
    
    libxl always uses xc_dom_gnttab_init(), which internally calls
    xc_dom_gnttab{_hvm,}_seed() to set up the grants point at the console and
    xenstore rings.  For HVM guests, libxl then asks Xen for the information set
    up previously, and calls xc_dom_gnttab_hvm_seed() a second time, which is
    wasteful.  ARM construction expects libxl to have set up
    dom->{console,xenstore}_evtchn earlier, so only actually functions because 
of
    this second call.
    
    Rationalise everything and make it consistent for all guests.
    
     1) Users of the domain builder are expected to provide
        dom->{console,xenstore}_{evtchn,domid} unconditionally.  This is checked
        by setting invalid values in xc_dom_allocate(), and checking in
        xc_dom_boot_image().
    
     2) For x86 HVM and ARM guests, the event channels are given to Xen at the
        same time as the ring gfns.  ARM already did this, but x86 is updated to
        match.  x86 PV already provides this information in the start_info page.
    
     3) Libxl is updated to drop all relevant functionality from
        hvm_build_set_params(), and behave consistently with PV guests when it
        comes to the handling of dom->{console,xenstore}_{evtchn,domid,gfn}.
    
    This removes several redundant hypercalls (including a foreign mapping) from
    the x86 HVM and ARM construction paths.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Tested-by: Julien Grall <julien.grall@xxxxxxx>
    Release-acked-by: Julien Grall <julien.grall@xxxxxxxxxx>

commit f48b5449dabc770acdde6d25cfbd265cfb71034d
Author: Wei Liu <wei.liu2@xxxxxxxxxx>
Date:   Thu Oct 12 20:19:07 2017 +0100

    tools/dombuilder: Switch to using gfn terminology for console and xenstore 
rings
    
    The sole use of xc_dom_translated() and xc_dom_p2m() outside of the domain
    builder is for libxl_dom() to translate the console and xenstore pfns back
    into useful values.  PV guest pfns are only interesting to the domain 
builder,
    and gfns are the address space used by all other hypercalls.
    
    Renaming the fields in xc_dom_image is deliberate, as it will cause
    out-of-tree users of the dombuilder to notice the different semantics.
    
    Correct the terminology throughout xc_dom_gnttab{_hvm,}_seed(), which are 
all
    using gfns despite the existing variable names.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Tested-by: Julien Grall <julien.grall@xxxxxxx>
    Release-acked-by: Julien Grall <julien.grall@xxxxxxxxxx>
    [ wei: fix stubdom build ]
    Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit 86cf189a957129ea1ad6468fe9a0887b9e2819f3
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Oct 12 20:19:06 2017 +0100

    tools/dombuilder: Remove clear_page() from xc_dom_boot.c
    
    pfn 0 is a legitimate (albeit unlikely) frame to use, so skipping it is 
wrong.
    This behaviour appears to exists simply to cover the fact that zero is the
    default value of an uninitialised field in dom.
    
    ARM already clears the frames at the point that the pfns are allocated,
    meaning that the added clear_page() is wasteful.  Alter x86 to match ARM and
    clear the page when it is allocated.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Tested-by: Julien Grall <julien.grall@xxxxxxx>
    Release-acked-by: Julien Grall <julien.grall@xxxxxxxxxx>

commit 716273c94077e354194c7236623fe3dfa34572d3
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Oct 12 20:19:05 2017 +0100

    tools/dombuilder: Drop more PVH v1 leftovers
    
    alloc_magic_pages() is renamed to alloc_magic_pages_pv() to mirror its
    alloc_magic_pages_hvm() counterpart.  Delete a redundant comment, introduce
    some newlines clarity, and remove a logically dead allocation of shared 
info.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Tested-by: Julien Grall <julien.grall@xxxxxxx>
    Release-acked-by: Julien Grall <julien.grall@xxxxxxxxxx>
(qemu changes not included)

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

 


Rackspace

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