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

Re: [Xen-devel] OVMF related osstest failures on multiple branches

(Adding Wei and Jan who I should have included before, thread starts at

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.


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

Xen-devel mailing list



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