[xen-unstable-smoke test] 99610: regressions - FAIL

[xen-unstable-smoke test] 99610: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   5 xen-build                 fail REGR. vs. 97725

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386  1 build-check(1)         blocked n/a
 test-armhf-armhf-xl          12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  db0eee0a071e2e3e18e79d21a9b1d6724edeeeb3
baseline version:
 xen                  a43cc8fc0827a4110b884b0fd94bf98628f27ab7

Last test of basis    97725  2016-07-20 18:03:39 Z    4 days
Testing same since    99610  2016-07-25 11:02:40 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Dario Faggioli <dario.faggioli@citrix.com>
  George Dunlap <george.dunlap@citrix.com>
  Julien Grall <julien.grall@arm.com>
  Sander Eikelenboom <linux@eikelenboom.it>

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


------------------------------------------------------------
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 db0eee0a071e2e3e18e79d21a9b1d6724edeeeb3
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Mon Jul 18 22:04:43 2016 +0100

    x86/vMSI-X: Fix host crash when shutting down guests with MSI capable devices
    
    c/s 74c6dc2d "x86/vMSI-X: defer intercept handler registration" caused MSI-X
    table infrastructure not to always be initialised, but it missed one path
    which needed an is-initialised check.
    
    If a devices is passed through to a domain which is MSI capable but not MSI-X
    capable, the call to msixtbl_init() is omitted, but a XEN_DOMCTL_unbind_pt_irq
    hypercall still calls into msixtbl_pt_unregister().  This follows the linked
    list pointer which is still NULL.
    
    Introduce an is-initalised check to msixtbl_pt_unregister().
    
    Furthermore, the purpose of the open-coded msixtbl_list.next check is rather
    subtle.  Introduce an msixtbl_initialised() predicate instead, which makes its
    purpose far more obvious.
    
    Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
    Reviewed-by: George Dunlap <george.dunlap@citrix.com>

commit d933b37eb404f27557e3e8468482c8ddaeaee60e
Author: Dario Faggioli <dario.faggioli@citrix.com>
Date:   Fri Jul 22 14:04:53 2016 +0200

    xen: credit2: don't let b_avgload go negative.
    
    The ASSERT() made effective by b5b5876619bd8ec2e
    ("xen: credit2: fix two s_time_t handling issues
    in load balancing") triggers for b_avgload (spotted
    by OSSTest).
    
    b_avgload is where we store the prediction of how
    the load of a runqueue will look like in the medium
    to long term, because of a vcpu being added to or
    removed from there.
    
    On vcpu removal, saturate down b_avgload to zero,
    as it makes very few sense to predict that the
    load of a runqueue will at some point become negative!
    
    Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
    Acked-by: George Dunlap <george.dunlap@citrix.com>

commit fcaa19dfac9b6050e87cb192217d748d9290de44
Author: Julien Grall <julien.grall@arm.com>
Date:   Wed Jul 20 17:10:46 2016 +0100

    xen/arm: p2m: Fix multi-lines coding style comments
    
    The start and end markers should be on separate lines.
    
    Signed-off-by: Julien Grall <julien.grall@arm.com>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

commit 74412ede07a756678f4c3324154a023cdcaf8f52
Author: Julien Grall <julien.grall@arm.com>
Date:   Wed Jul 20 17:10:45 2016 +0100

    xen/arm: p2m: Restrict usage of get_page_from_gva to the current vCPU
    
    The function get_page_from_gva translates a guest virtual address to a
    machine address. The translation involves the register VTTBR_EL2,
    TTBR0_EL1, TTBR1_EL1 and SCTLR_EL1.
    
    Currently, only the first register is context switch is the current
    domain is not the same. This will result to use the wrong TTBR*_EL1 and
    SCTLR_EL1 for the translation.
    
    To fix the code properly, we would have to context switch all the
    registers mentioned above when the vCPU in parameter is not the current
    one. Similar things would need to be done in the callee
    p2m_mem_check_and_get_page.
    
    Given that the only caller of this function with the vCPU that may not
    be current is a guest debugging function (show_guest_stack), restrict
    the usage to the current vCPU for the time being.
    
    Signed-off-by: Julien Grall <julien.grall@arm.com>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

commit 7b3d480221e0ff4814675388fe375f21ba87bc26
Author: Julien Grall <julien.grall@arm.com>
Date:   Wed Jul 20 17:10:44 2016 +0100

    xen/arm: p2m: Pass the vCPU in parameter to get_page_from_gva
    
    The function get_page_from_gva translates a guest virtual address to a
    machine address. The translation involves the register VTTBR_EL2,
    TTBR0_EL1, TTBR1_EL1 and SCTLR_EL1. Whilst the first register is per
    domain (the p2m is common to every vCPUs), the last 3 are per-vCPU.
    
    Therefore, the function should take the vCPU in parameter and not the
    domain. Fixing the actual code path will be done a separate patch.
    
    Signed-off-by: Julien Grall <julien.grall@arm.com>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

commit c3cfccdd007a81bc6cfc31851111523880089cbd
Author: Julien Grall <julien.grall@arm.com>
Date:   Wed Jul 20 17:10:43 2016 +0100

    xen/arm: system: Use the correct parameter name in local_irq_restore
    
    The parameter to store the flags is called 'x' and not 'flags'.
    Thankfully all the user of the macro is passing 'flags'.
    
    Signed-off-by: Julien Grall <julien.grall@arm.com>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
(qemu changes not included)

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

xenbits and https redirect (was Re: [xen-unstable-smoke test] 99610: regressions - FAIL)

[Ian Jackson]

osstest service owner writes ("[xen-unstable-smoke test] 99610: regressions - FAIL"):
> flight 99610 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/99610/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   5 xen-build    fail REGR. vs. 97725

fatal: unable to access
'https://xenbits.xen.org/git-http/mini-os.git/': Failed to connect to
xenbits.xen.org port 443: Connection refused

This is because:

1. xen.git specifies the url http://xenbits.xen.org/git-http/mini-os.git/

2. xenbits has/had a redirect to https, as part of our transition to
   using https everywhere.

3. So the xen.git build tries to access
   https://xenbits.xen.org/git-http/mini-os.git/

4. The http_proxy variable set by osstest to try to make http requests
   by build systems go via the cacheing proxy is not effective for
   https

5. The colo firewall intentionally prevents general accesses to the
   global internet by builds (or indeed tests) run by osstest.
   One purpose is to prevent uncached accesses, which are a
   performance and reliability problem.

This is hard to fix because:

6. Using the https_proxy variable would not help.  It would cause
   libcurl (which is what git is using) to use CONNECT.  That is
   not what we need: we need the client to trust the proxy, so
   that we can get cacheing.

7. squid would support proxying GET https:// requests but there is
   AFAICT no way for curl to do this (even in fairly recent curl).
   I found this thread on the subject:
     https://curl.haxx.se/mail/archive-2015-12/0009.html

I think in the medium term the right answer is for osstest to use its
git cacheing proxy, rather than trying to cache the http[s] protocol,
by specifying a .gitconfig involving insteadOf.

For now I have asked Credativ to disable the https redirect on
xenbits.

I would be interested to know whether this redirect caused other
problems.  Should we reenable it when osstest is improved ?

When should we change the http:// references in xen.git to https:// ?

Thanks,
Ian.

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

Re: xenbits and https redirect (was Re: [xen-unstable-smoke test] 99610: regressions - FAIL)

[George Dunlap]

On Mon, Jul 25, 2016 at 4:24 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> osstest service owner writes ("[xen-unstable-smoke test] 99610: regressions - FAIL"):
>> flight 99610 xen-unstable-smoke real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/99610/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  build-amd64                   5 xen-build    fail REGR. vs. 97725
>
> fatal: unable to access
> 'https://xenbits.xen.org/git-http/mini-os.git/': Failed to connect to
> xenbits.xen.org port 443: Connection refused
>
> This is because:
>
> 1. xen.git specifies the url http://xenbits.xen.org/git-http/mini-os.git/
>
> 2. xenbits has/had a redirect to https, as part of our transition to
>    using https everywhere.
>
> 3. So the xen.git build tries to access
>    https://xenbits.xen.org/git-http/mini-os.git/
>
> 4. The http_proxy variable set by osstest to try to make http requests
>    by build systems go via the cacheing proxy is not effective for
>    https
>
> 5. The colo firewall intentionally prevents general accesses to the
>    global internet by builds (or indeed tests) run by osstest.
>    One purpose is to prevent uncached accesses, which are a
>    performance and reliability problem.
>
> This is hard to fix because:
>
> 6. Using the https_proxy variable would not help.  It would cause
>    libcurl (which is what git is using) to use CONNECT.  That is
>    not what we need: we need the client to trust the proxy, so
>    that we can get cacheing.
>
> 7. squid would support proxying GET https:// requests but there is
>    AFAICT no way for curl to do this (even in fairly recent curl).
>    I found this thread on the subject:
>      https://curl.haxx.se/mail/archive-2015-12/0009.html
>
> I think in the medium term the right answer is for osstest to use its
> git cacheing proxy, rather than trying to cache the http[s] protocol,
> by specifying a .gitconfig involving insteadOf.
>
> For now I have asked Credativ to disable the https redirect on
> xenbits.
>
> I would be interested to know whether this redirect caused other
> problems.  Should we reenable it when osstest is improved ?
>
> When should we change the http:// references in xen.git to https:// ?

Once we're confident that the https urls work properly, is there any
reason to wait?

Or to put it differently, why not do it right now?

 -George

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