Xen 4.6, OVMF and arm64

Xen 4.6, OVMF and arm64

[Stefano Stabellini]

Hi Wei, Anthony,

the OVMF revision that we use with Xen 4.6 is
cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd, however that doesn't work for
arm64. It is not a problem for xen.git, because the arm64 build of ovmf
is not enabled in the xen tree (it is built separately). However it is a
problem for raisin: I am trying to enable the ovmf build on arm64 in
raisin but it fails on arm64 for the latest release (at least on CentOS
7) which is not nice.

One fix is required on top of
cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd to make it work:

commit 28e80befa4fe0edd7cce876e991fed912f0f2795
Author: Leif Lindholm <leif.lindholm@linaro.org>
Date:   Thu Jul 9 16:29:44 2015 +0000

    BaseTools: aarch64: add -fno-asynchronous-unwind-tables to gcc cflags


This is not required but it would be nice:

commit ad2a2e5623a4a4ac5f24ae827f7842995ef4c2a9
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Wed Aug 12 05:22:49 2015 +0000

    BaseTools: add ARCH detection for AARCH64 and ARM


They only affect aarch64. Do you think it would be possible to apply
them to the ovfm tree on xenbits and maybe update the ovmf revision in
Config.mk, once it passes any required osstest tests?

Thanks,

Stefano

Re: Xen 4.6, OVMF and arm64

[Wei Liu]

On Wed, Oct 14, 2015 at 12:25:32PM +0100, Stefano Stabellini wrote:
> Hi Wei, Anthony,
> 
> the OVMF revision that we use with Xen 4.6 is
> cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd, however that doesn't work for
> arm64. It is not a problem for xen.git, because the arm64 build of ovmf
> is not enabled in the xen tree (it is built separately). However it is a
> problem for raisin: I am trying to enable the ovmf build on arm64 in
> raisin but it fails on arm64 for the latest release (at least on CentOS
> 7) which is not nice.
> 
> One fix is required on top of
> cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd to make it work:
> 
> commit 28e80befa4fe0edd7cce876e991fed912f0f2795
> Author: Leif Lindholm <leif.lindholm@linaro.org>
> Date:   Thu Jul 9 16:29:44 2015 +0000
> 
>     BaseTools: aarch64: add -fno-asynchronous-unwind-tables to gcc cflags
> 
> 
> This is not required but it would be nice:
> 
> commit ad2a2e5623a4a4ac5f24ae827f7842995ef4c2a9
> Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Date:   Wed Aug 12 05:22:49 2015 +0000
> 
>     BaseTools: add ARCH detection for AARCH64 and ARM
> 
> 
> They only affect aarch64. Do you think it would be possible to apply
> them to the ovfm tree on xenbits and maybe update the ovmf revision in
> Config.mk, once it passes any required osstest tests?
> 

I can send a patch for Config.mk when the patch passed our tests.

Wei.

> Thanks,
> 
> Stefano

Re: Xen 4.6, OVMF and arm64

[Stefano Stabellini]

On Wed, 14 Oct 2015, Wei Liu wrote:
> On Wed, Oct 14, 2015 at 12:25:32PM +0100, Stefano Stabellini wrote:
> > Hi Wei, Anthony,
> > 
> > the OVMF revision that we use with Xen 4.6 is
> > cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd, however that doesn't work for
> > arm64. It is not a problem for xen.git, because the arm64 build of ovmf
> > is not enabled in the xen tree (it is built separately). However it is a
> > problem for raisin: I am trying to enable the ovmf build on arm64 in
> > raisin but it fails on arm64 for the latest release (at least on CentOS
> > 7) which is not nice.
> > 
> > One fix is required on top of
> > cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd to make it work:
> > 
> > commit 28e80befa4fe0edd7cce876e991fed912f0f2795
> > Author: Leif Lindholm <leif.lindholm@linaro.org>
> > Date:   Thu Jul 9 16:29:44 2015 +0000
> > 
> >     BaseTools: aarch64: add -fno-asynchronous-unwind-tables to gcc cflags
> > 
> > 
> > This is not required but it would be nice:
> > 
> > commit ad2a2e5623a4a4ac5f24ae827f7842995ef4c2a9
> > Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Date:   Wed Aug 12 05:22:49 2015 +0000
> > 
> >     BaseTools: add ARCH detection for AARCH64 and ARM
> > 
> > 
> > They only affect aarch64. Do you think it would be possible to apply
> > them to the ovfm tree on xenbits and maybe update the ovmf revision in
> > Config.mk, once it passes any required osstest tests?
> > 
> 
> I can send a patch for Config.mk when the patch passed our tests.

OK, thanks. But can you also cherry-pick them into
git://xenbits.xen.org/ovmf.git ?

Re: Xen 4.6, OVMF and arm64

[Wei Liu]

On Wed, Oct 14, 2015 at 12:29:32PM +0100, Wei Liu wrote:
> On Wed, Oct 14, 2015 at 12:25:32PM +0100, Stefano Stabellini wrote:
> > Hi Wei, Anthony,
> > 
> > the OVMF revision that we use with Xen 4.6 is
> > cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd, however that doesn't work for
> > arm64. It is not a problem for xen.git, because the arm64 build of ovmf
> > is not enabled in the xen tree (it is built separately). However it is a
> > problem for raisin: I am trying to enable the ovmf build on arm64 in
> > raisin but it fails on arm64 for the latest release (at least on CentOS
> > 7) which is not nice.
> > 
> > One fix is required on top of
> > cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd to make it work:
> > 
> > commit 28e80befa4fe0edd7cce876e991fed912f0f2795
> > Author: Leif Lindholm <leif.lindholm@linaro.org>
> > Date:   Thu Jul 9 16:29:44 2015 +0000
> > 
> >     BaseTools: aarch64: add -fno-asynchronous-unwind-tables to gcc cflags
> > 
> > 
> > This is not required but it would be nice:
> > 
> > commit ad2a2e5623a4a4ac5f24ae827f7842995ef4c2a9
> > Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Date:   Wed Aug 12 05:22:49 2015 +0000
> > 
> >     BaseTools: add ARCH detection for AARCH64 and ARM
> > 
> > 
> > They only affect aarch64. Do you think it would be possible to apply
> > them to the ovfm tree on xenbits and maybe update the ovmf revision in
> > Config.mk, once it passes any required osstest tests?
> > 
> 
> I can send a patch for Config.mk when the patch passed our tests.
> 

In fact, I think all three patches you referred to are now in
xen-tested-master branch. I will send a patch to Config.mk soon.

Wei.

> Wei.
> 
> > Thanks,
> > 
> > Stefano

Re: Xen 4.6, OVMF and arm64

[Wei Liu]

On Wed, Oct 14, 2015 at 12:30:15PM +0100, Stefano Stabellini wrote:
> On Wed, 14 Oct 2015, Wei Liu wrote:
> > On Wed, Oct 14, 2015 at 12:25:32PM +0100, Stefano Stabellini wrote:
> > > Hi Wei, Anthony,
> > > 
> > > the OVMF revision that we use with Xen 4.6 is
> > > cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd, however that doesn't work for
> > > arm64. It is not a problem for xen.git, because the arm64 build of ovmf
> > > is not enabled in the xen tree (it is built separately). However it is a
> > > problem for raisin: I am trying to enable the ovmf build on arm64 in
> > > raisin but it fails on arm64 for the latest release (at least on CentOS
> > > 7) which is not nice.
> > > 
> > > One fix is required on top of
> > > cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd to make it work:
> > > 
> > > commit 28e80befa4fe0edd7cce876e991fed912f0f2795
> > > Author: Leif Lindholm <leif.lindholm@linaro.org>
> > > Date:   Thu Jul 9 16:29:44 2015 +0000
> > > 
> > >     BaseTools: aarch64: add -fno-asynchronous-unwind-tables to gcc cflags
> > > 
> > > 
> > > This is not required but it would be nice:
> > > 
> > > commit ad2a2e5623a4a4ac5f24ae827f7842995ef4c2a9
> > > Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > > Date:   Wed Aug 12 05:22:49 2015 +0000
> > > 
> > >     BaseTools: add ARCH detection for AARCH64 and ARM
> > > 
> > > 
> > > They only affect aarch64. Do you think it would be possible to apply
> > > them to the ovfm tree on xenbits and maybe update the ovmf revision in
> > > Config.mk, once it passes any required osstest tests?
> > > 
> > 
> > I can send a patch for Config.mk when the patch passed our tests.
> 
> OK, thanks. But can you also cherry-pick them into
> git://xenbits.xen.org/ovmf.git ?

I don't have commit access. 

What I normally do is to ask committers to do it when I send my patch --
it's a bit cumbersome, but at least it works.

Wei.

Re: Xen 4.6, OVMF and arm64

[Ian Campbell]

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=refs/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).

Ian.

Re: Xen 4.6, OVMF and arm64

[Stefano Stabellini]

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=refs/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?

Re: Xen 4.6, OVMF and arm64

[Wei Liu]

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=refs/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.

Wei.

Re: Xen 4.6, OVMF and arm64

[Stefano Stabellini]

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=refs/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?

Re: Xen 4.6, OVMF and arm64

[Ian Campbell]

On Wed, 2015-10-14 at 13:55 +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=refs/he
> > ads/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?

My point was only that we don't have one now, not that we shouldn't have
one.

Ian.

Re: Xen 4.6, OVMF and arm64

[Wei Liu]

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=refs/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.

Wei.

Re: Xen 4.6, OVMF and arm64

[Ian Campbell]

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.

Re: Xen 4.6, OVMF and arm64

[Wei Liu]

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.

Re: Xen 4.6, OVMF and arm64

[Stefano Stabellini]

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.

Re: Xen 4.6, OVMF and arm64

[Ian Campbell]

On Wed, 2015-10-14 at 14:51 +0100, Stefano Stabellini wrote:
> 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.

Please bear in mind that what you are asking is has consequences outside of
raisin which are not necessarily simple.

Right now we do not having a branching strategy for ovmf, so cherry-picking
fixes for aarch64 means someone would need to come up with one and
implement it. There are also the implications which Wei raised.

Based on Wei's comments regarding support from upstream it seems like we
should probably just pull ovmf forward to something newer (~= current
tested master based on x86 testing) for 4.6.1.

Ian.

Re: Xen 4.6, OVMF and arm64

[Stefano Stabellini]

On Wed, 14 Oct 2015, Ian Campbell wrote:
> On Wed, 2015-10-14 at 14:51 +0100, Stefano Stabellini wrote:
> > 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.
> 
> Please bear in mind that what you are asking is has consequences outside of
> raisin which are not necessarily simple.
> 
> Right now we do not having a branching strategy for ovmf, so cherry-picking
> fixes for aarch64 means someone would need to come up with one and
> implement it. There are also the implications which Wei raised.
> 
> Based on Wei's comments regarding support from upstream it seems like we
> should probably just pull ovmf forward to something newer (~= current
> tested master based on x86 testing) for 4.6.1.

That's fine for me

Re: Xen 4.6, OVMF and arm64

[Ian Campbell]

On Wed, 2015-10-14 at 15:11 +0100, Stefano Stabellini wrote:
> On Wed, 14 Oct 2015, Ian Campbell wrote:
> > On Wed, 2015-10-14 at 14:51 +0100, Stefano Stabellini wrote:
> > > 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.
> > 
> > Please bear in mind that what you are asking is has consequences
> > outside of
> > raisin which are not necessarily simple.
> > 
> > Right now we do not having a branching strategy for ovmf, so cherry
> > -picking
> > fixes for aarch64 means someone would need to come up with one and
> > implement it. There are also the implications which Wei raised.
> > 
> > Based on Wei's comments regarding support from upstream it seems like
> > we
> > should probably just pull ovmf forward to something newer (~= current
> > tested master based on x86 testing) for 4.6.1.
> 
> That's fine for me

I think this corresponds to backporting the patch Wei sent out earlier:

From: Wei Liu <wei.liu2@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: [...]
Subject: [PATCH] Config.mk: update OVMF changeset
Date: Wed, 14 Oct 2015 12:41:13 +0100
Message-id: <1444822873-28287-1-git-send-email-wei.liu2@citrix.com>

I'll try and remember to mention this when I commit.

Ian.