Re: [Xen-devel] Xen 4.6, OVMF and arm64

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 14 Oct 2015, Ian Campbell wrote:
> On Wed, 2015-10-14 at 14:24 +0100, Wei Liu wrote:
> > On Wed, Oct 14, 2015 at 02:04:48PM +0100, Stefano Stabellini wrote:
> > > On Wed, 14 Oct 2015, Wei Liu wrote:
> > > > On Wed, Oct 14, 2015 at 01:55:39PM +0100, Stefano Stabellini wrote:
> > > > > On Wed, 14 Oct 2015, Ian Campbell wrote:
> > > > > > On Wed, 2015-10-14 at 12:29 +0100, Wei Liu wrote:
> > > > > > > I can send a patch for Config.mk when the patch passed our
> > > > > > > tests.
> > > > > > 
> > > > > > For xen-unstable I think we should just move up to
> > > > > >  http://xenbits.xen.org/gitweb/?p=osstest/ovmf.git;a=shortlog;h=r
> > > > > > efs/heads/xen-tested-master
> > > > > > 
> > > > > > We don't have any separate tests for ovmf in 4.6 (since there is
> > > > > > currently
> > > > > > no correpsonding git branch to even test, I think) so the only
> > > > > > way to
> > > > > > trigger those would be to backport a Config.mk change (again, I
> > > > > > think).
> > > > >  
> > > > > Maybe we should have a separate tree/branch for ovmf 4.6? What if a
> > > > > bug
> > > > > is found?
> > > > 
> > > > In theory we can. But OVMF doesn't make release so this tree / branch
> > > > would be hard to manage. EDK (UDK?) makes release, but we don't know
> > > > yet
> > > > how it's managed, and we don't know whether OVMF developer care about
> > > > those releases enough to backport their fixes.
> > > 
> > > Couldn't we choose a baseline, for example
> > > cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd, then backport to it any
> > > commits, or fixes that  we deem necessary?
> > 
> > Yes, that's possible but the implication needs to be considered
> > carefully.
> > 
> > Up until now we depend on upstream to fix bugs and then update our own
> > tree, and then respective patches propagate to our tree, and then we ask
> > for backport of Config.mk update to propagate the fix to stable
> > branches.  This scheme has minimal workload  for us.
> > 
> > Choosing an arbitrary commit as baseline would mean we don't actually
> > get support from upstream (I don't think anyone would be interested in
> > helping maintaining a arbitrary fork, just think about someone who forks
> > xen.git at arbitrary commit and asks for fix for issue). In the long run
> > this might cause us problem, too much maintenance burden -- considering
> > each Xen stable release needs to be maintained for an extended period of
> > time and OVMF is a fast moving target.
> 
> Given that we have zero automated testing of arm64 and certainly do not
> test ovmf on arm64 in osstest I don't think the fact that some given commit
> is in Config.mk or in some tree of ours on xenbits tells us anything at all
> about the suitability/usefulness/etc of that commit for OVMF on arm64 Xen.
> Nor does it give us any reason to declare that we will "support" that
> version in any meaningful way.
> 
> IMHO we may as well just point Raisin users building on arm64 to the
> upstream master branch.
> 
> We essentially have exactly the same amount of confidence in it as we do in
> what is in Config.mk (with or without cherry picks).
 
I am very practical in this regard and I just don't want the raisin
build to fail on arm64 with xen 4.6.  We could have a different raisin
config file, with a different ovmf revision for Xen 4.6 on arm64, but I
would prefer to avoid it: I think it is nicer and simpler if one config
file per Xen release was provided, no matter the underlying arch.
In other words ovmf is built separately on raisin on x86 too, but I
would prefer if we used the same ovmf revision for all archs.

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