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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Oct 14, 2015 at 02:35:57PM +0100, 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.
> 

Yes.

> 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).
> 

Right, indeed.

Wei.

> Ian.

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