OVMF related osstest failures on multiple branches

OVMF related osstest failures on multiple branches

[Ian Campbell]

These two tests are failing all over the place at the moment:
    test-amd64-i386-xl-qemuu-ovmf-amd64.debian-hvm-install
    test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install

For the rest of this mail I will only consider the test-amd64-amd64-* one,
assuming they are the same.

The issues appear to have started on 18/12 last year.

Affected branches seem to be:
    xen-4.6-testing, xen-4.5-testing, xen-4.4-testing
    qemu-upstream-4.6-testing, qemu-upstream-4.5-testing, qemu-upstream-4.4-testing

xen-unstable appears to be unaffected.

qemu-mainline is blocked by a build failure.

qemu-upstream-unstable is OK, it had a pass on 18/12, so it's possible that
if the issue is elsewhere this tree simply hasn't seen it yet.

(links to all branch histories are below for convenience)

All branches have had a pass with ovmf revision cb9a7ebabcd6 and are still
using that version now during the failures. I don't think this is an
ovmf.git issue.

In all trees multiple revisions changed over the "event horizon" (i.e. when
the failures occurred), the following summarises what changed for each:

		pass/fail host		osstest	linux	qemuu	xen
xen 4.6		godello1/rimava0	Y[0]	N[4]	N[6]	Y[8]
xen 4.5		pinot0/huxelrebe1	Y[0]	N[4]	N[6]	Y[8]
xen 4.4		rimava1/italia0		Y[0]	N[4]	N[6]	Y[9]	

qemu 4.6	rimava1/baroque1	Y[1]	Y[5]	Y[7]	Y[10]
qemu 4.5[11]	chardonay0/chardonay1	Y[2]	Y[5]	Y[7]	Y[10]
qemu 4.4	elbling1/huxelrebe1	Y[3]	Y[5]	Y[7]	Y

[0] osstest: af4a02e671de..f610ea162836 == update to Jessie
[1] osstest: 54f237784d4b..f610ea162836
[2] osstest: f795781327c0..f610ea162836
[3] osstest: 3cd8b12a4fb1..f610ea162836
[4] Linux 3.14.58
[5] Linux updated from various versions (54, 50, 54) to 3.14.58
[6] qemuu 980dfcf5b8d8
[7] Two XSA-155 fixes
[8] qemut updated for XSA-155.
[9] Fixes for XSA-165 and XSA-166
[10] Lots of changes, from September/October 2015 until now, not including 
     XSA-155, -165 or -166.
[11] Flight before event horizon is 62414, which failed a later step, but 
     is considered a pass of the debian-hvm-install step.

The hosts also all changed, but there is no apparent pattern to the failing
hosts.

Given that Xen * passes with Linux 3.14.58 I doubt the change of Linux in
the QEMU flights to use that version is the issue.

Given that QEMU didn't change in Xen * it seems unlikely that it is the
XSA-155 fixes in the QEMU flights which are causing this.

Given that the xen changes in the Xen * branches all post date the version
of Xen ones in the QEMU * branches, I doubt it is those (especially the
qemut only changes).

Which basically only leaves the switch to using a Debian Jessie build and
runtime environment. As well as the host side stuff we also change the
Debian HVM ISO from Wheezy to Jessie. The fact that none of the bisects
have made any progress (Xen * failed to repro basis pass, QEMU * didn't
seem to find a basis pass to start with) seems to support this.

The fly in the ointment of this theory is that the Jessie upgrade doesn't
seem to have broken unstable in this way, for some reason, which is what I
intend to investigate first.

Ian.

Job histories:

http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-ovmf-amd64/xen-4.6-testing.html
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-ovmf-amd64/xen-4.5-testing.html
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-ovmf-amd64/xen-4.4-testing.html

http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-ovmf-amd64/qemu-upstream-4.6-testing.html
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-ovmf-amd64/qemu-upstream-4.5-testing.html
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-ovmf-amd64/qemu-upstream-4.4-testing.html

Bisects:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.6-testing/test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install.html
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.5-testing/test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install.html
(4.4 hasn't tackled this one yet)

http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-upstream-4.6-testing/test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install.html
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-upstream-4.5-testing/test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install.html
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-upstream-4.4-testing/test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install.html


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

Re: OVMF related osstest failures on multiple branches

[Ian Campbell]

On Wed, 2016-01-06 at 12:35 +0000, Ian Campbell wrote:
> The fly in the ointment of this theory is that the Jessie upgrade doesn't
> seem to have broken unstable in this way, for some reason, which is what I
> intend to investigate first.

One difference between all the failing versions and xen-unstable is that
unstable has a newer OVMF 52a99493cce8 (works) vs cb9a7ebabcd6 (fails).

It's possible there is a fix in there which would explain this, but its a
lot of commits to trawl through.

That said, one did stand out (below). A hang would correlate with a
complete lack of output (serial, vga) in the failure case (e.g. the 4.6-
testing one at [0]). Jessie is GCC49.

Next step is I'm trying 4.6-testing with the newer OVMF to see if this is
worth pursuing.

Ian.

[0] http://logs.test-lab.xenproject.org/osstest/logs/76950/test-amd64-amd64-xl-qemuu-ovmf-amd64/info.html)

Ian.


commit 55e96f9c601781b8dc52c40747922f6ca3521f9e
Author: Ruiyu Ni <ruiyu.ni@intel.com>
Date:   Thu Jul 9 08:55:23 2015 +0000

    OvmfPkg: Fix GCC49 build hang in PeiCore
    
    PeiCore hang when loads a PEIM whose section alignment requirement is 0x40
    but the actual base address is 0x20 aligned.
    
    The issue is caused by the following facts, in order:
    
    1. GCC49 requires the section alignment of .data to be 0x40. So a new link
       script gcc4.9-ld-script was added for GCC49 to specify the 0x40
       alignment.
    
    2. GenFw tool was enhanced to sync ELF's section alignment to PE header.
       Before the enhancement, the section alignment of converted PE image
       always equals to 0x20.
    
    If only with #1 change, GCC49 build image won't hang in PeiCore because
    the converted PE image still claims 0x20 section alignment which is
    aligned to the align setting set in FDF file. But later with #2 change,
    the converted PE image starts to claims 0x40 section alignment, while
    build tool still puts the PEIM in 0x20 aligned address, resulting the
    PeCoffLoaderLoadImage() reports IMAGE_ERROR_INVALID_SECTION_ALIGNMENT
    error.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
    Reviewed-by: Liming Gao <liming.gao@intel.com>
    Reviewed-by: Laszlo Ersek <lersek@redhat.com>
    
    git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17902 6f19259b-4bc3-4df7-8a09-765794883524


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

Re: OVMF related osstest failures on multiple branches

[Ian Campbell]

(Adding Wei and Jan who I should have included before, thread starts at
 http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00442.html )

On Wed, 2016-01-06 at 14:27 +0000, Ian Campbell wrote:


> Next step is I'm trying 4.6-testing with the newer OVMF to see if this is
> worth pursuing.

Running xen-4.6-testing with ovmf.git 52a99493cce8 instead of cb9a7ebabcd6
does seem to have worked (i.e. the flight hasn't actually finished yet but
it has passed the debian-hvm-install step).

We have in the past, after much discussion[0], backported changes to
Config.mk:OVMF_UPSTREAM_REVISION to pull forward wholesale to a newer ovmf.

On another (more recent) occasion there have been strong objections to
doing so[1]. I think we concluded there that we should add stable-X.Y
branches to git://xenbits.xen.org/ovmf.git and cherry-pick fixes, the
reason nothing happened then was that the backport in question was a
feature request for ovmf on arm64 which is not something we test and was
not therefore something I was comfortable with.

If we consider [0] as precedent then we would want to backport
xen.git 04c5efb0a141 and f046e501bbc to staging-4.4, -4.5 and -4.6 to bring
those branches up to ovmf.git 52a99493cce8.

If we want to follow [1] then the plan of attack is:
 * I need to identify the patch(es) which actually fix this issue and
   cherrypick it into new stable branches in ovmf.git for 4.4, 4.5 and 4.6.
 * Ian J to update OVMF_UPSTREAM_REVISION in the corresponding xen.git
   stable branches to point to all those commits (either branch name or
   SHA, not sure).
 * The release checklist needs updating to include tagging this new tree
   and updating OVMF_UPSTREAM_REVISION to point to the tag instead of the
   commit (I think this is strictly speaking option, but we should do it).
 * We might want to consider retroactively tagging the versions of ovmf
   used in 4.4.[01234], 4.5.[012] and 4.6.0 in ovmf.git, which would be
   helpful for people using gitk etc to look at the history I suppose 

That assumes a seabios/qemut style model to updating ovmf, i.e. ungated
manual Config.mk update, if we were to switch to a gate it would be
different but regardless of the merits of doing things that way it does't
seem like a thing to do on a stable branch.

Ian.

[0] http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04428.html
[1] http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg02381.html
 stemming from
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01534.html

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

Re: OVMF related osstest failures on multiple branches

[Jan Beulich]

>>> On 06.01.16 at 16:28, <ian.campbell@citrix.com> wrote:
> Running xen-4.6-testing with ovmf.git 52a99493cce8 instead of cb9a7ebabcd6
> does seem to have worked (i.e. the flight hasn't actually finished yet but
> it has passed the debian-hvm-install step).
> 
> We have in the past, after much discussion[0], backported changes to
> Config.mk:OVMF_UPSTREAM_REVISION to pull forward wholesale to a newer ovmf.
> 
> On another (more recent) occasion there have been strong objections to
> doing so[1]. I think we concluded there that we should add stable-X.Y
> branches to git://xenbits.xen.org/ovmf.git and cherry-pick fixes, the
> reason nothing happened then was that the backport in question was a
> feature request for ovmf on arm64 which is not something we test and was
> not therefore something I was comfortable with.
> 
> If we consider [0] as precedent then we would want to backport
> xen.git 04c5efb0a141 and f046e501bbc to staging-4.4, -4.5 and -4.6 to bring
> those branches up to ovmf.git 52a99493cce8.
> 
> If we want to follow [1] then the plan of attack is:

I'm afraid I can't easily build an opinion which of the two is the
lesser evil. I guess as long as we consider OVMF use experimental
(do we?), following [0] would be the slightly more natural approach.

Jan

>  * I need to identify the patch(es) which actually fix this issue and
>    cherrypick it into new stable branches in ovmf.git for 4.4, 4.5 and 4.6.
>  * Ian J to update OVMF_UPSTREAM_REVISION in the corresponding xen.git
>    stable branches to point to all those commits (either branch name or
>    SHA, not sure).
>  * The release checklist needs updating to include tagging this new tree
>    and updating OVMF_UPSTREAM_REVISION to point to the tag instead of the
>    commit (I think this is strictly speaking option, but we should do it).
>  * We might want to consider retroactively tagging the versions of ovmf
>    used in 4.4.[01234], 4.5.[012] and 4.6.0 in ovmf.git, which would be
>    helpful for people using gitk etc to look at the history I suppose 
> 
> That assumes a seabios/qemut style model to updating ovmf, i.e. ungated
> manual Config.mk update, if we were to switch to a gate it would be
> different but regardless of the merits of doing things that way it does't
> seem like a thing to do on a stable branch.
> 
> Ian.
> 
> [0] 
> http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04428.html 
> [1] 
> http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg02381.html 
>  stemming from
> http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01534.html 

Re: OVMF related osstest failures on multiple branches

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] OVMF related osstest failures on multiple branches"):
> On 06.01.16 at 16:28, <ian.campbell@citrix.com> wrote:
> > Running xen-4.6-testing with ovmf.git 52a99493cce8 instead of cb9a7ebabcd6
> > does seem to have worked (i.e. the flight hasn't actually finished yet but
> > it has passed the debian-hvm-install step).

Great.  So AFAICT we would conclude that Debian jessie does not work
with the older OVMF.

> > If we want to follow [1] then the plan of attack is:
...
> >  * I need to identify the patch(es) which actually fix this issue and
> >    cherrypick it into new stable branches in ovmf.git for 4.4, 4.5 and 4.6.
> >  * Ian J to update OVMF_UPSTREAM_REVISION in the corresponding xen.git
> >    stable branches to point to all those commits (either branch name or
> >    SHA, not sure).
> >  * The release checklist needs updating to include tagging this new tree
> >    and updating OVMF_UPSTREAM_REVISION to point to the tag instead of the
> >    commit (I think this is strictly speaking option, but we should do it).
> >  * We might want to consider retroactively tagging the versions of ovmf
> >    used in 4.4.[01234], 4.5.[012] and 4.6.0 in ovmf.git, which would be
> >    helpful for people using gitk etc to look at the history I suppose 
> > 
> > That assumes a seabios/qemut style model to updating ovmf, i.e. ungated
> > manual Config.mk update, if we were to switch to a gate it would be
> > different but regardless of the merits of doing things that way it does't
> > seem like a thing to do on a stable branch.

This is quite a lot of work.  Doing this work would perhaps make sense
if we had a reasonable idea what was going on in ovmf.git, which
changes to cherry pick to stable branches, etc.  But AFAICT we don't.

So I would be tempted to just update the Config.mk reference in stable
trees.

Ian.

Re: OVMF related osstest failures on multiple branches

[Wei Liu]

On Wed, Jan 06, 2016 at 03:28:30PM +0000, Ian Campbell wrote:
> (Adding Wei and Jan who I should have included before, thread starts at
>  http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00442.html )
> 
> On Wed, 2016-01-06 at 14:27 +0000, Ian Campbell wrote:
> 
> 
> > Next step is I'm trying 4.6-testing with the newer OVMF to see if this is
> > worth pursuing.
> 
> Running xen-4.6-testing with ovmf.git 52a99493cce8 instead of cb9a7ebabcd6
> does seem to have worked (i.e. the flight hasn't actually finished yet but
> it has passed the debian-hvm-install step).
> 
> We have in the past, after much discussion[0], backported changes to
> Config.mk:OVMF_UPSTREAM_REVISION to pull forward wholesale to a newer ovmf.
> 
> On another (more recent) occasion there have been strong objections to
> doing so[1]. I think we concluded there that we should add stable-X.Y
> branches to git://xenbits.xen.org/ovmf.git and cherry-pick fixes, the
> reason nothing happened then was that the backport in question was a
> feature request for ovmf on arm64 which is not something we test and was
> not therefore something I was comfortable with.
> 
> If we consider [0] as precedent then we would want to backport
> xen.git 04c5efb0a141 and f046e501bbc to staging-4.4, -4.5 and -4.6 to bring
> those branches up to ovmf.git 52a99493cce8.
> 
> If we want to follow [1] then the plan of attack is:
>  * I need to identify the patch(es) which actually fix this issue and
>    cherrypick it into new stable branches in ovmf.git for 4.4, 4.5 and 4.6.
>  * Ian J to update OVMF_UPSTREAM_REVISION in the corresponding xen.git
>    stable branches to point to all those commits (either branch name or
>    SHA, not sure).
>  * The release checklist needs updating to include tagging this new tree
>    and updating OVMF_UPSTREAM_REVISION to point to the tag instead of the
>    commit (I think this is strictly speaking option, but we should do it).
>  * We might want to consider retroactively tagging the versions of ovmf
>    used in 4.4.[01234], 4.5.[012] and 4.6.0 in ovmf.git, which would be
>    helpful for people using gitk etc to look at the history I suppose 
> 
> That assumes a seabios/qemut style model to updating ovmf, i.e. ungated
> manual Config.mk update, if we were to switch to a gate it would be
> different but regardless of the merits of doing things that way it does't
> seem like a thing to do on a stable branch.

FWIW I think [0] is easier. We certainly don't want to understand every
single commit in EDK2 in order to backport stuff. Currently it's over 3
million LOC.

Wei.

Re: OVMF related osstest failures on multiple branches

[Ian Campbell]

On Wed, 2016-01-06 at 16:28 +0000, Ian Jackson wrote:
> Jan Beulich writes ("Re: [Xen-devel] OVMF related osstest failures on
> multiple branches"):
> > On 06.01.16 at 16:28, <ian.campbell@citrix.com> wrote:
> > > Running xen-4.6-testing with ovmf.git 52a99493cce8 instead of
> > > cb9a7ebabcd6
> > > does seem to have worked (i.e. the flight hasn't actually finished
> > > yet but
> > > it has passed the debian-hvm-install step).
> 
> Great.  So AFAICT we would conclude that Debian jessie does not work
> with the older OVMF.

Strictly speaking Jessie's compiler cannot build a working OVMF binary.

Jessie as a guest appears to work just fine.

> > > If we want to follow [1] then the plan of attack is:
> ...
> > >  * I need to identify the patch(es) which actually fix this issue and
> > >    cherrypick it into new stable branches in ovmf.git for 4.4, 4.5
> > > and 4.6.
> > >  * Ian J to update OVMF_UPSTREAM_REVISION in the corresponding
> > > xen.git
> > >    stable branches to point to all those commits (either branch name
> > > or
> > >    SHA, not sure).
> > >  * The release checklist needs updating to include tagging this new
> > > tree
> > >    and updating OVMF_UPSTREAM_REVISION to point to the tag instead of
> > > the
> > >    commit (I think this is strictly speaking option, but we should do
> > > it).
> > >  * We might want to consider retroactively tagging the versions of
> > > ovmf
> > >    used in 4.4.[01234], 4.5.[012] and 4.6.0 in ovmf.git, which would
> > > be
> > >    helpful for people using gitk etc to look at the history I suppose
> > > 
> > > That assumes a seabios/qemut style model to updating ovmf, i.e.
> > > ungated
> > > manual Config.mk update, if we were to switch to a gate it would be
> > > different but regardless of the merits of doing things that way it
> > > does't
> > > seem like a thing to do on a stable branch.
> 
> This is quite a lot of work.  Doing this work would perhaps make sense
> if we had a reasonable idea what was going on in ovmf.git, which
> changes to cherry pick to stable branches, etc.  But AFAICT we don't.

FWIW adding just 39ef30bb47b6 to cb9a7ebabcd6 seems to have worked, but
finding that was based on a search for "GCC" in the commit log and a wild
hunch ;-).

> So I would be tempted to just update the Config.mk reference in stable
> trees.

That's my inclination too.

Ian.

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

Re: OVMF related osstest failures on multiple branches

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] OVMF related osstest failures on multiple branches"):
> [Ian Jackson:]
> > So I would be tempted to just update the Config.mk reference in stable
> > trees.
> 
> That's my inclination too.

Let's give it another day to see if anyone objects.  I not, I will do
this tomorrow.

Ian.

Re: OVMF related osstest failures on multiple branches

[Ian Jackson]

Ian Jackson writes ("Re: [Xen-devel] OVMF related osstest failures on multiple branches"):
> Let's give it another day to see if anyone objects.  I not, I will do
> this tomorrow.

I am just about to push this to staging-4.6 and will backport it to
earlier branches as applicable.

Ian.

>From 6c3c6ff9ecaa5ee0be8b535d36fdcd12380564a1 Mon Sep 17 00:00:00 2001
From: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 14 Oct 2015 12:41:13 +0100
Subject: [PATCH] Config.mk: update OVMF changeset

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

(cherry picked from commit 04c5efb0a141fa53e805e396970419436e74ce67)

Apropos of discussion in
 "OVMF related osstest failures on multiple branches"
 http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00442.html

We believe the older ovmf.git does not work when built with the gcc in
Debian jessie.  We do not know where this bug lies but we are fixing
it by updating ovmf.

We have decided that we are not in a position to review the changes to
OVMF upstream, and ourselves decide what to cherry pick.  Instead we
will update the revision wholesale and use the xen.git stable
branches' push gate.

Conflicts:
	Config.mk

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 5ba36aa..e829f7e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -253,7 +253,7 @@ QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xen-traditional.git
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
 endif
-OVMF_UPSTREAM_REVISION ?= cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd
+OVMF_UPSTREAM_REVISION ?= af9785a9ed61daea52b47f0bf448f1f228beee1e
 QEMU_UPSTREAM_REVISION ?= qemu-xen-4.6.0
 MINIOS_UPSTREAM_REVISION ?= xen-RELEASE-4.6.0
 # Fri Jun 26 11:58:40 2015 +0100
-- 
1.7.10.4

Re: OVMF related osstest failures on multiple branches

[Ian Campbell]

On Thu, 2016-01-07 at 15:36 +0000, Ian Jackson wrote:
>  endif
> -OVMF_UPSTREAM_REVISION ?= cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd
> +OVMF_UPSTREAM_REVISION ?= af9785a9ed61daea52b47f0bf448f1f228beee1e

This should be:
 OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d

You've picked up 04c5efb0a141 but not f046e501bbc I think, we should take
both, since that's what I've tested if nothing else.

Ian.

>  QEMU_UPSTREAM_REVISION ?= qemu-xen-4.6.0
>  MINIOS_UPSTREAM_REVISION ?= xen-RELEASE-4.6.0
>  # Fri Jun 26 11:58:40 2015 +0100

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

Re: OVMF related osstest failures on multiple branches

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] OVMF related osstest failures on multiple branches"):
> On Thu, 2016-01-07 at 15:36 +0000, Ian Jackson wrote:
> >  endif
> > -OVMF_UPSTREAM_REVISION ?= cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd
> > +OVMF_UPSTREAM_REVISION ?= af9785a9ed61daea52b47f0bf448f1f228beee1e
> 
> This should be:
>  OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
> 
> You've picked up 04c5efb0a141 but not f046e501bbc I think, we should take
> both, since that's what I've tested if nothing else.

Oops.  I had pushed only to 4.6, to which I have followed up with:

>From 1d3cc6e62c4d2fc3dd9251d4921881425c9d27bd Mon Sep 17 00:00:00 2001
From: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 12 Nov 2015 10:06:58 +0000
Subject: [PATCH] Config.mk: update OVMF changeset

The new osstest tested head contains a fix for gcc-4.4 toolchain.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(cherry picked from commit f046e501bbca1c8a46853b2e1f1b587e228c73de)

This should have been folded into the previous commit.

Conflicts:
	Config.mk

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 e829f7e..1eb53d7 100644
--- a/Config.mk
+++ b/Config.mk
@@ -253,7 +253,7 @@ QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xen-traditional.git
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
 endif
-OVMF_UPSTREAM_REVISION ?= af9785a9ed61daea52b47f0bf448f1f228beee1e
+OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
 QEMU_UPSTREAM_REVISION ?= qemu-xen-4.6.0
 MINIOS_UPSTREAM_REVISION ?= xen-RELEASE-4.6.0
 # Fri Jun 26 11:58:40 2015 +0100
-- 
1.7.10.4

Re: OVMF related osstest failures on multiple branches

[Ian Jackson]

Ian Jackson writes ("Re: [Xen-devel] OVMF related osstest failures on multiple branches"):
> Oops.  I had pushed only to 4.6, to which I have followed up with:

The change has now been made back to 4.3.

In 4.3, OVMF_UPSTREAM_REVISION was b0855f92 rather than cb9a7eba.
I have pulled in the additional changes, willy-nilly.
    
Ian.