[xen-unstable test] 24870: regressions - trouble: broken/fail/pass

[xen-unstable test] 24870: regressions - trouble: broken/fail/pass

[xen.org]

[-- Attachment #1: Type: text/plain, Size: 12507 bytes --]

flight 24870 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/24870/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            3 host-build-prep           fail REGR. vs. 24862

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           9 guest-start                  fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  4e8d89bc1445f91c4c6c7bf0ad8d51b0c809841e
baseline version:
 xen                  d883c179a74111a6804baf8cb8224235242a88fc

------------------------------------------------------------
People who touched revisions under test:
  "Zhang, Yang Z" <yang.z.zhang@intel.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <julien.grall@linaro.org>
  Keir Fraser <keir@xen.org>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  Mukesh Rathor <mukesh.rathor@oracle.com>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monné <roger.pau@citrix.com>
  Tim Deegan <tim@xen.org>
  Yang Zhang <yang.z.zhang@Intel.com>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-i386-freebsd10-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-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 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
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 4e8d89bc1445f91c4c6c7bf0ad8d51b0c809841e
Author: Mukesh Rathor <mukesh.rathor@oracle.com>
Date:   Thu Feb 13 17:56:39 2014 +0100

    pvh: Fix regression due to assumption that HVM paths MUST use io-backend device
    
    The commit 09bb434748af9bfe3f7fca4b6eef721a7d5042a4
    "Nested VMX: prohibit virtual vmentry/vmexit during IO emulation"
    assumes that the HVM paths are only taken by HVM guests. With the PVH
    enabled that is no longer the case - which means that we do not have
    to have the IO-backend device (QEMU) enabled.
    
    As such, that patch can crash the hypervisor:
    
    Xen call trace:
        [<ffff82d0801ddd9a>] nvmx_switch_guest+0x4d/0x903
        [<ffff82d0801de95b>] vmx_asm_vmexit_handler+0x4b/0xc0
    
    Pagetable walk from 000000000000001e:
      L4[0x000] = 0000000000000000 ffffffffffffffff
    
    ****************************************
    Panic on CPU 7:
    FATAL PAGE FAULT
    [error_code=0000]
    Faulting linear address: 000000000000001e
    ****************************************
    
    as we do not have an io based backend. In the case that the
    PVH guest does run an HVM guest inside it - we need to do
    further work to suport this - and for now the check will
    bail us out.
    
    We also fix spelling mistakes and the sentence structure.
    
    Suggested-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
    Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: "Zhang, Yang Z" <yang.z.zhang@intel.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>

commit 077fc1c04d70ef1748ac2daa6622b3320a1a004c
Author: Yang Zhang <yang.z.zhang@Intel.com>
Date:   Thu Feb 13 15:50:22 2014 +0000

    When enabling log dirty mode, it sets all guest's memory to readonly.
    And in HAP enabled domain, it modifies all EPT entries to clear write bit
    to make sure it is readonly. This will cause problem if VT-d shares page
    table with EPT: the device may issue a DMA write request, then VT-d engine
    tells it the target memory is readonly and result in VT-d fault.
    
    Currnetly, there are two places will enable log dirty mode: migration and vram
    tracking. Migration with device assigned is not allowed, so it is ok. For vram,
    it doesn't need to set all memory to readonly. Only track the vram range is enough.
    
    Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
    Acked-by: Tim Deegan <tim@xen.org>

commit 0e251a8371574b905d37d7650d1d625caf0f1181
Author: Tim Deegan <tim@xen.org>
Date:   Thu Feb 13 15:13:07 2014 +0000

    xen: Don't use __builtin_stdarg_start().
    
    Cset fca49a00 ("netbsd: build fix with gcc 4.5") changed the
    definition of va_start() to use __builtin_va_start() rather than
    __builtin_stdarg_start() for GCCs >= 4.5, but in fact GCC dropped
    __builtin_stdarg_start() before v3.3.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Tested-by: Roger Pau Monné <roger.pau@citrix.com>

commit d2985386925fab3abe075852db46df29b56c95bb
Author: Olaf Hering <olaf@aepfle.de>
Date:   Thu Feb 13 15:43:24 2014 +0100

    docs: mention whitespace handling diskspec target= parsing
    
    disk=[ ' target=/dev/loop0 ' ] will fail to parse because
    '/dev/loop ' does not exist.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 0873829a70daa3c23d03b9841ccd529f05889f21
Author: Tim Deegan <tim@xen.org>
Date:   Thu Feb 13 12:13:58 2014 +0000

    xen: stop trying to use the system <stdarg.h> and <stdbool.h>
    
    We already have our own versions of the stdarg/stdbool definitions, for
    systems where those headers are installed in /usr/include.
    
    On linux, they're typically installed in compiler-specific paths, but
    finding them has proved unreliable.  Drop that and use our own versions
    everywhere.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Tested-by: Julien Grall <julien.grall@linaro.org>
    Acked-by: Keir Fraser <keir@xen.org>

commit 42788ddd24a06bf05f0f2b5da1880ed89736bd7b
Author: Jan Beulich <JBeulich@suse.com>
Date:   Thu Feb 13 12:57:43 2014 +0000

    tools/configure: correct --enable-blktap1 help text
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 1278b09cc5a38da4efbe0de37a7f9fab9d19f913
Author: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date:   Tue Feb 11 10:25:17 2014 -0500

    docs/vtpm: fix auto-shutdown reference
    
    The automatic shutdown feature of the vTPM was removed because it
    interfered with pv-grub measurement support and was also not triggered
    if the guest did not use the vTPM. Virtual TPM domains will need to be
    shut down or destroyed on guest shutdown via a script or other user
    action.
    
    This also fixes an incorrect reference to the vTPM being PV-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 001bdcee7bc19be3e047d227b4d940c04972eb02
Author: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date:   Thu Feb 13 10:49:55 2014 +0100

    x86/pci: Store VF's memory space displacement in a 64-bit value
    
    VF's memory space offset can be greater than 4GB and therefore needs
    to be stored in a 64-bit variable.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

commit 3ac3817762d1a8b39fa45998ec8c40cabfcfc802
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Wed Feb 12 14:27:37 2014 +0000

    xl: suppress suspend/resume functions on platforms which do not support it.
    
    ARM does not (currently) support migration, so stop offering tasty looking
    treats like "xl migrate".
    
    Apart from the UI improvement my intention is to use this in osstest to detect
    whether to attempt the save/restore/migrate tests.
    
    Other than the additions of the #define/#ifdef there is a tiny bit of code
    motion ("dump-core" in the command list and core_dump_domain in the
    implementations) which serves to put ifdeffable bits next to each other.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)


[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Proposed force push of staging to master

[Ian Jackson]

xen.org writes ("[xen-unstable test] 24870: regressions - trouble: broken/fail/pass"):
> flight 24870 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/24870/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-oldkern            3 host-build-prep       fail REGR. vs. 24862

This was the "usual" failure: Citrix's intercepting web proxy causes
some hg clones of linux-2.6.18.hg from xenbits to fail.  The rest of
the flight was successful.

The rest of the weekend's tests were badly affected by a disk failure
on earwig.  So as a result we didn't get a push.

I cleared out a bunch of other stuff running in the test system in an
effort to get a pass sooner, but peeking at the results the same job
has failed the same way in the currently-running flight.  So we won't
get a push in that iteration either.

We should consider doing a force push for RC4.  The risks are:
 * There is something actually wrong with xen.git which causes the
   32-bit 2.6.18 build to fail;
 * Less resistance in the future to 2.6.18 build failures.
I'll discuss these in turn.

The build-*-oldkern tests involve using the kernel-building machinery
in xen.git to clone 2.6.18 from xenbits and build it.  Firstly, I think
it's unlikely that anything in xen.git#d883c179..4e8d89bc would affect
that.  Secondly, the build-amd64-oldkern builds have passed.  So I
think we can almost entirely discount the first risk.

I think the second risk is tolerable.  We should keep an eye on it for
a bit and if it turns out that the oldkern build really does become
broken later and as a result keeps failing indefinitely, we will be
able to spot that.

So, we propose to push 4e8d89bc1445f91c4c6c7bf0ad8d51b0c809841e to
xen.git#master and call it RC4.  Comments welcome.

Ian.

Re: Proposed force push of staging to master

[Jan Beulich]

>>> On 17.02.14 at 13:08, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> xen.org writes ("[xen-unstable test] 24870: regressions - trouble: 
> broken/fail/pass"):
>> flight 24870 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/24870/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  build-i386-oldkern            3 host-build-prep       fail REGR. vs. 24862
> 
> This was the "usual" failure: Citrix's intercepting web proxy causes
> some hg clones of linux-2.6.18.hg from xenbits to fail.  The rest of
> the flight was successful.
> 
> The rest of the weekend's tests were badly affected by a disk failure
> on earwig.  So as a result we didn't get a push.
> 
> I cleared out a bunch of other stuff running in the test system in an
> effort to get a pass sooner, but peeking at the results the same job
> has failed the same way in the currently-running flight.  So we won't
> get a push in that iteration either.
> 
> We should consider doing a force push for RC4.  The risks are:
>  * There is something actually wrong with xen.git which causes the
>    32-bit 2.6.18 build to fail;
>  * Less resistance in the future to 2.6.18 build failures.
> I'll discuss these in turn.
> 
> The build-*-oldkern tests involve using the kernel-building machinery
> in xen.git to clone 2.6.18 from xenbits and build it.  Firstly, I think
> it's unlikely that anything in xen.git#d883c179..4e8d89bc would affect
> that.  Secondly, the build-amd64-oldkern builds have passed.  So I
> think we can almost entirely discount the first risk.
> 
> I think the second risk is tolerable.  We should keep an eye on it for
> a bit and if it turns out that the oldkern build really does become
> broken later and as a result keeps failing indefinitely, we will be
> able to spot that.
> 
> So, we propose to push 4e8d89bc1445f91c4c6c7bf0ad8d51b0c809841e to
> xen.git#master and call it RC4.  Comments welcome.

On the basis of the almost-push mentioned above, I agree,
irrespective of the apparent regression I'm facing.

Jan

Re: Proposed force push of staging to master

[George Dunlap]

On 02/17/2014 12:08 PM, Ian Jackson wrote:
> xen.org writes ("[xen-unstable test] 24870: regressions - trouble: broken/fail/pass"):
>> flight 24870 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/24870/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>   build-i386-oldkern            3 host-build-prep       fail REGR. vs. 24862
> This was the "usual" failure: Citrix's intercepting web proxy causes
> some hg clones of linux-2.6.18.hg from xenbits to fail.  The rest of
> the flight was successful.
>
> The rest of the weekend's tests were badly affected by a disk failure
> on earwig.  So as a result we didn't get a push.
>
> I cleared out a bunch of other stuff running in the test system in an
> effort to get a pass sooner, but peeking at the results the same job
> has failed the same way in the currently-running flight.  So we won't
> get a push in that iteration either.
>
> We should consider doing a force push for RC4.  The risks are:
>   * There is something actually wrong with xen.git which causes the
>     32-bit 2.6.18 build to fail;
>   * Less resistance in the future to 2.6.18 build failures.
> I'll discuss these in turn.
>
> The build-*-oldkern tests involve using the kernel-building machinery
> in xen.git to clone 2.6.18 from xenbits and build it.  Firstly, I think
> it's unlikely that anything in xen.git#d883c179..4e8d89bc would affect
> that.  Secondly, the build-amd64-oldkern builds have passed.  So I
> think we can almost entirely discount the first risk.
>
> I think the second risk is tolerable.  We should keep an eye on it for
> a bit and if it turns out that the oldkern build really does become
> broken later and as a result keeps failing indefinitely, we will be
> able to spot that.
>
> So, we propose to push 4e8d89bc1445f91c4c6c7bf0ad8d51b0c809841e to
> xen.git#master and call it RC4.  Comments welcome.

Thanks for the analysis.  This seems like a good plan.

  -George

Re: Proposed force push of staging to master

[Ian Jackson]

George Dunlap writes ("Re: Proposed force push of staging to master"):
> On 02/17/2014 12:08 PM, Ian Jackson wrote:
> > So, we propose to push 4e8d89bc1445f91c4c6c7bf0ad8d51b0c809841e to
> > xen.git#master and call it RC4.  Comments welcome.
> 
> Thanks for the analysis.  This seems like a good plan.

I have done this (RC4 is tagged, tarballs are in production).

I also had to force push the change below to xen.git#master.

Can I request that we don't change this back to say "master" until we
are done with 4.4.0 ?  Either way we have to update Config.mk with new
qemu upstream versions, but if we set this to "master" in between RCs,
I end up having to do it as a force push in the middle of the RC
production which is out-of-course, error-prone, and suboptimal.

It is IMO better to put a commit hash in QEMU_UPSTREAM_REVISION in
Config.mk (updated when the qemu-upstream tree has passed its push
gate).

That is I think the best workflow is:
  * make a change to staging/qemu-upstream-unstable.git
  * wait for push gate to put it in qemu-upstream-unstable.git
  * make change to xen.git#staging to update QEMU_UPSTREAM_REVISION
    to new commit hash
  * whatever is in xen.git#master is what gets called rcN
    (ie we tag xen.git and */qemu-upstream-unstable.git with the rcN
     tags, but we don't use the actual tag name in Config.mk)

Thanks,
Ian.

>From b7319350278d0220febc8a7dc8be8e8d41b0abd2 Mon Sep 17 00:00:00 2001
From: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 17 Feb 2014 16:33:48 +0000
Subject: [PATCH] Update QEMU_UPSTREAM_REVISION for 4.4.0-rc4

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Config.mk |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index 1e034f7..a6cd2e3 100644
--- a/Config.mk
+++ b/Config.mk
@@ -234,7 +234,7 @@ QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 endif
 OVMF_UPSTREAM_REVISION ?= 447d264115c476142f884af0be287622cd244423
-QEMU_UPSTREAM_REVISION ?= master
+QEMU_UPSTREAM_REVISION ?= qemu-xen-4.4.0-rc4
 SEABIOS_UPSTREAM_TAG ?= rel-1.7.3.1
 # Fri Aug 2 14:12:09 2013 -0400
 # Fix bug in CBFS file walking with compressed files.
-- 
1.7.10.4

Re: Proposed force push of staging to master

[Jan Beulich]

>>> On 17.02.14 at 17:49, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> George Dunlap writes ("Re: Proposed force push of staging to master"):
>> On 02/17/2014 12:08 PM, Ian Jackson wrote:
>> > So, we propose to push 4e8d89bc1445f91c4c6c7bf0ad8d51b0c809841e to
>> > xen.git#master and call it RC4.  Comments welcome.
>> 
>> Thanks for the analysis.  This seems like a good plan.
> 
> I have done this (RC4 is tagged, tarballs are in production).
> 
> I also had to force push the change below to xen.git#master.
> 
> Can I request that we don't change this back to say "master" until we
> are done with 4.4.0 ?  Either way we have to update Config.mk with new
> qemu upstream versions, but if we set this to "master" in between RCs,
> I end up having to do it as a force push in the middle of the RC
> production which is out-of-course, error-prone, and suboptimal.
> 
> It is IMO better to put a commit hash in QEMU_UPSTREAM_REVISION in
> Config.mk (updated when the qemu-upstream tree has passed its push
> gate).
> 
> That is I think the best workflow is:
>   * make a change to staging/qemu-upstream-unstable.git
>   * wait for push gate to put it in qemu-upstream-unstable.git
>   * make change to xen.git#staging to update QEMU_UPSTREAM_REVISION
>     to new commit hash
>   * whatever is in xen.git#master is what gets called rcN
>     (ie we tag xen.git and */qemu-upstream-unstable.git with the rcN
>      tags, but we don't use the actual tag name in Config.mk)

Do you propose this just for the RC phase, or do you propose
reverting the decision to have this set to master altogether? In either
case, it was only pretty recently that we decided to use master here,
and I don't think you objected, so I'm a little puzzled by the proposal.
I personally think that using master and an explicit tag for RCs is just
as appropriate as properly naming the RC in
xen/Makefile:XEN_EXTRAVERSION, and that doing the respective
adjustments could - if one wanted to - likely be fully automated (albeit
when I'm doing the same on the stable branches, I didn't bother
scripting this so far as it's just not happening frequently enough to
warrant this).

Jan

Re: Proposed force push of staging to master

[Stefano Stabellini]

On Mon, 17 Feb 2014, Ian Jackson wrote:
> George Dunlap writes ("Re: Proposed force push of staging to master"):
> > On 02/17/2014 12:08 PM, Ian Jackson wrote:
> > > So, we propose to push 4e8d89bc1445f91c4c6c7bf0ad8d51b0c809841e to
> > > xen.git#master and call it RC4.  Comments welcome.
> > 
> > Thanks for the analysis.  This seems like a good plan.
> 
> I have done this (RC4 is tagged, tarballs are in production).
> 
> I also had to force push the change below to xen.git#master.
> 
> Can I request that we don't change this back to say "master" until we
> are done with 4.4.0 ?  Either way we have to update Config.mk with new
> qemu upstream versions, but if we set this to "master" in between RCs,
> I end up having to do it as a force push in the middle of the RC
> production which is out-of-course, error-prone, and suboptimal.
> 
> It is IMO better to put a commit hash in QEMU_UPSTREAM_REVISION in
> Config.mk (updated when the qemu-upstream tree has passed its push
> gate).
> 
> That is I think the best workflow is:
>   * make a change to staging/qemu-upstream-unstable.git
>   * wait for push gate to put it in qemu-upstream-unstable.git

Does this work because the test infrastructure doesn't obey Config.mk?
Otherwise how could the new changes be tested if QEMU_UPSTREAM_REVISION
in Config.mk is unchanged?

In fact, even if the test infrastructure does test the new changes by
manually setting QEMU_UPSTREAM_REVISION, following your proposed
workflow we would still miss all the possible bug reports from the
community between RCs.
It doesn't seem very community friendly to me.


>   * make change to xen.git#staging to update QEMU_UPSTREAM_REVISION
>     to new commit hash
>   * whatever is in xen.git#master is what gets called rcN
>     (ie we tag xen.git and */qemu-upstream-unstable.git with the rcN
>      tags, but we don't use the actual tag name in Config.mk)
> 
> Thanks,
> Ian.
> 
> >From b7319350278d0220febc8a7dc8be8e8d41b0abd2 Mon Sep 17 00:00:00 2001
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Date: Mon, 17 Feb 2014 16:33:48 +0000
> Subject: [PATCH] Update QEMU_UPSTREAM_REVISION for 4.4.0-rc4
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  Config.mk |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Config.mk b/Config.mk
> index 1e034f7..a6cd2e3 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -234,7 +234,7 @@ QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
>  SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
>  endif
>  OVMF_UPSTREAM_REVISION ?= 447d264115c476142f884af0be287622cd244423
> -QEMU_UPSTREAM_REVISION ?= master
> +QEMU_UPSTREAM_REVISION ?= qemu-xen-4.4.0-rc4
>  SEABIOS_UPSTREAM_TAG ?= rel-1.7.3.1
>  # Fri Aug 2 14:12:09 2013 -0400
>  # Fix bug in CBFS file walking with compressed files.
> -- 
> 1.7.10.4
> 

Re: Proposed force push of staging to master [and 1 more messages]

[Ian Jackson]

Jan Beulich writes ("Re: Proposed force push of staging to master"):
> Do you propose this just for the RC phase, or do you propose
> reverting the decision to have this set to master altogether?

Just for the RC phase.

> In either case, it was only pretty recently that we decided to use
> master here, and I don't think you objected, so I'm a little puzzled
> by the proposal.

We decided to use master here "most of the time".

> I personally think that using master and an explicit tag for RCs is just
> as appropriate as properly naming the RC in
> xen/Makefile:XEN_EXTRAVERSION, and that doing the respective
> adjustments could - if one wanted to - likely be fully automated (albeit
> when I'm doing the same on the stable branches, I didn't bother
> scripting this so far as it's just not happening frequently enough to
> warrant this).

Yes, I agree that it could be automated.  But there's a problem with
doing this on a routine basis.  As you can see from the test report
just sent, a force push requires osstest to construct a new baseline
test.  If that baseline test suffers from some kind of passing problem
(eg, infrastructure problems, or git servers being down at the wrong
moment, or whatever), then osstest wouldn't be able to spot any actual
regressions in the affected tests.

An alternative would be to make these part-of-the-release changes on a
separate git branch, but then people who want to test an RC would have
to do something other than just "git clone xen.git".

It would be possible to have osstest spot the force push and try to
find a tested ancestor of the current master to use as a baseline.
But that would make it impossible to use a forced push to deliberately
introduce a known but tolerable regression.

Stefano Stabellini writes ("Re: Proposed force push of staging to master"):
> On Mon, 17 Feb 2014, Ian Jackson wrote:
> > That is I think the best workflow is:
> >   * make a change to staging/qemu-upstream-unstable.git
> >   * wait for push gate to put it in qemu-upstream-unstable.git
> 
> Does this work because the test infrastructure doesn't obey Config.mk?

Yes.

> In fact, even if the test infrastructure does test the new changes by
> manually setting QEMU_UPSTREAM_REVISION, following your proposed
> workflow we would still miss all the possible bug reports from the
> community between RCs.

I'm suggesting that whenever the qemu-upstream tree is updated, the
hash in Config.mk should be updated too, the way it's done for qemu
trad.

Ian.

Re: Proposed force push of staging to master

[Ian Campbell]

On Tue, 2014-02-18 at 10:57 +0000, Stefano Stabellini wrote:
> On Mon, 17 Feb 2014, Ian Jackson wrote:
> > George Dunlap writes ("Re: Proposed force push of staging to master"):
> > > On 02/17/2014 12:08 PM, Ian Jackson wrote:
> > > > So, we propose to push 4e8d89bc1445f91c4c6c7bf0ad8d51b0c809841e to
> > > > xen.git#master and call it RC4.  Comments welcome.
> > > 
> > > Thanks for the analysis.  This seems like a good plan.
> > 
> > I have done this (RC4 is tagged, tarballs are in production).
> > 
> > I also had to force push the change below to xen.git#master.
> > 
> > Can I request that we don't change this back to say "master" until we
> > are done with 4.4.0 ?  Either way we have to update Config.mk with new
> > qemu upstream versions, but if we set this to "master" in between RCs,
> > I end up having to do it as a force push in the middle of the RC
> > production which is out-of-course, error-prone, and suboptimal.
> > 
> > It is IMO better to put a commit hash in QEMU_UPSTREAM_REVISION in
> > Config.mk (updated when the qemu-upstream tree has passed its push
> > gate).
> > 
> > That is I think the best workflow is:
> >   * make a change to staging/qemu-upstream-unstable.git
> >   * wait for push gate to put it in qemu-upstream-unstable.git
> 
> Does this work because the test infrastructure doesn't obey Config.mk?

For the test flights which target testing of new qemu bits osstest
overrides the version to pick up the new stuff.

For test flights which target testing of Xen itself Config.mk is obeyed.

> Otherwise how could the new changes be tested if QEMU_UPSTREAM_REVISION
> in Config.mk is unchanged?

By the qemu specific flights.

Ian.

Re: Proposed force push of staging to master

[Ian Campbell]

On Mon, 2014-02-17 at 16:49 +0000, Ian Jackson wrote:
> George Dunlap writes ("Re: Proposed force push of staging to master"):
> > On 02/17/2014 12:08 PM, Ian Jackson wrote:
> > > So, we propose to push 4e8d89bc1445f91c4c6c7bf0ad8d51b0c809841e to
> > > xen.git#master and call it RC4.  Comments welcome.
> > 
> > Thanks for the analysis.  This seems like a good plan.
> 
> I have done this (RC4 is tagged, tarballs are in production).
> 
> I also had to force push the change below to xen.git#master.
> 
> Can I request that we don't change this back to say "master" until we
> are done with 4.4.0 ?  Either way we have to update Config.mk with new
> qemu upstream versions, but if we set this to "master" in between RCs,
> I end up having to do it as a force push in the middle of the RC
> production which is out-of-course, error-prone, and suboptimal.
> 
> It is IMO better to put a commit hash in QEMU_UPSTREAM_REVISION in
> Config.mk (updated when the qemu-upstream tree has passed its push
> gate).
> 
> That is I think the best workflow is:
>   * make a change to staging/qemu-upstream-unstable.git
>   * wait for push gate to put it in qemu-upstream-unstable.git
>   * make change to xen.git#staging to update QEMU_UPSTREAM_REVISION
>     to new commit hash

This seems to be prone to being forgotten, can we get osstest (or
something else) to send us^WStefano^Wxen-devel a persistent reminder
when there is a mismatch between xen.git:Config.mk and
qemu-upstream.git#master?

Ian.