Re: Stable backport request for new OVMF version

From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Stable backport request for new OVMF version
Date: Thu, 23 Jul 2015 16:31:33 +0100	[thread overview]
Message-ID: <20150723153133.GD12377@zion.uk.xensource.com> (raw)
In-Reply-To: <55B1242F0200007800094BC3@prv-mh.provo.novell.com>

On Thu, Jul 23, 2015 at 09:28:15AM -0600, Jan Beulich wrote:
> >>> On 23.07.15 at 16:58, <ian.campbell@citrix.com> wrote:
> > On Thu, 2015-07-23 at 08:51 -0600, Jan Beulich wrote:
> >> > 
> >> > > > On 23.07.15 at 16:43, <ian.campbell@citrix.com> wrote:
> >> > On Thu, 2015-07-23 at 08:26 -0600, Jan Beulich wrote:
> >> > > > 
> >> > > > > > On 23.07.15 at 15:56, <ian.campbell@citrix.com> wrote:
> >> > > > The version of OVMF in 4.5 (and presumably earlier) doesn't 
> >> > > > build 
> >> > > > with
> >> > > > the gcc in modern Linux distros (I noticed it with 4.9 from
> >> > > > Debian/Jessie).
> >> > > > 
> >> > > > I think we should update Config.mk:OVMF_UPSTREAM_REVISION to
> >> > > > cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd in all stable 
> >> > > > branches. 
> >> > > > That
> >> > > > version is the one currently in master.
> >> > > 
> >> > > To be honest I didn't even know we support use of OVMF in any
> >> > > released version (nor in unstable). When did this change?
> >> > 
> >> > It was present in 4.3. I don't think we build it by default since 
> >> > its
> >> > toolchain is a bit picky, but we turn it on and test it in osstest 
> >> > from
> >> > 4.4 onwards.
> >> > 
> >> > You can ask for it with bios="ovmf" in your hvm guest's config.
> >> 
> >> Well, that means it can be used by the adventurous, but it doesn't
> >> mean we consider it supported.
> > 
> > TBH, I'm more concerned that it is a blocker for upgrade osstest to
> > Debian Jessie, which in turn is a prerequisite for testing arm64.
> 
> If it was explicitly unsupported, I could say "do whatever you need
> to do to it", but with not being sure what status it has I'm kind of
> wondering what other changes (i.e. apart from fixing the build) the
> tree(s) would get which then may break someone. But in the end
> it's probably okay to do the change.
> 

It's marked as experimental, not supported and not built by default --
if that makes you feel more comfortable.

Wei.

> Jan