From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: OVMF related osstest failures on multiple branches Date: Wed, 6 Jan 2016 16:50:55 +0000 Message-ID: <20160106165055.GO27789@citrix.com> References: <1452083701.21055.43.camel@citrix.com> <1452090477.21055.48.camel@citrix.com> <1452094110.21055.81.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <1452094110.21055.81.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Wei Liu , Stefano Stabellini , Ian Jackson , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org 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 > =A0http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00442.h= tml=A0) > = > 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=A052a99493cce8 instead of=A0cb9a7eb= abcd6 > 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 ovm= f. > = > 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=A0git://xenbits.xen.org/ovmf.git=A0and 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=A004c5efb0a141 and=A0f046e501bbc 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=A0 > = > 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.