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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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

Ian.

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