* Xen 4.6, OVMF and arm64 @ 2015-10-14 11:25 Stefano Stabellini 2015-10-14 11:29 ` Wei Liu 0 siblings, 1 reply; 17+ messages in thread From: Stefano Stabellini @ 2015-10-14 11:25 UTC (permalink / raw) To: Wei Liu; +Cc: anthony.perard, xen-devel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 11:25 Xen 4.6, OVMF and arm64 Stefano Stabellini @ 2015-10-14 11:29 ` Wei Liu 2015-10-14 11:30 ` Stefano Stabellini ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Wei Liu @ 2015-10-14 11:29 UTC (permalink / raw) To: Stefano Stabellini; +Cc: anthony.perard, xen-devel, 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 11:29 ` Wei Liu @ 2015-10-14 11:30 ` Stefano Stabellini 2015-10-14 11:35 ` Wei Liu 2015-10-14 11:32 ` Wei Liu 2015-10-14 11:38 ` Ian Campbell 2 siblings, 1 reply; 17+ messages in thread From: Stefano Stabellini @ 2015-10-14 11:30 UTC (permalink / raw) To: Wei Liu; +Cc: anthony.perard, xen-devel, 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 ? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 11:30 ` Stefano Stabellini @ 2015-10-14 11:35 ` Wei Liu 0 siblings, 0 replies; 17+ messages in thread From: Wei Liu @ 2015-10-14 11:35 UTC (permalink / raw) To: Stefano Stabellini; +Cc: anthony.perard, xen-devel, 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 11:29 ` Wei Liu 2015-10-14 11:30 ` Stefano Stabellini @ 2015-10-14 11:32 ` Wei Liu 2015-10-14 11:38 ` Ian Campbell 2 siblings, 0 replies; 17+ messages in thread From: Wei Liu @ 2015-10-14 11:32 UTC (permalink / raw) To: Stefano Stabellini; +Cc: anthony.perard, xen-devel, 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 11:29 ` Wei Liu 2015-10-14 11:30 ` Stefano Stabellini 2015-10-14 11:32 ` Wei Liu @ 2015-10-14 11:38 ` Ian Campbell 2015-10-14 12:55 ` Stefano Stabellini 2 siblings, 1 reply; 17+ messages in thread From: Ian Campbell @ 2015-10-14 11:38 UTC (permalink / raw) To: Wei Liu, Stefano Stabellini; +Cc: anthony.perard, xen-devel 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 11:38 ` Ian Campbell @ 2015-10-14 12:55 ` Stefano Stabellini 2015-10-14 13:04 ` Wei Liu 2015-10-14 13:05 ` Ian Campbell 0 siblings, 2 replies; 17+ messages in thread From: Stefano Stabellini @ 2015-10-14 12:55 UTC (permalink / raw) To: Ian Campbell; +Cc: anthony.perard, xen-devel, Wei Liu, 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 12:55 ` Stefano Stabellini @ 2015-10-14 13:04 ` Wei Liu 2015-10-14 13:04 ` Stefano Stabellini 2015-10-14 13:05 ` Ian Campbell 1 sibling, 1 reply; 17+ messages in thread From: Wei Liu @ 2015-10-14 13:04 UTC (permalink / raw) To: Stefano Stabellini; +Cc: anthony.perard, xen-devel, Wei Liu, Ian Campbell 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 13:04 ` Wei Liu @ 2015-10-14 13:04 ` Stefano Stabellini 2015-10-14 13:24 ` Wei Liu 0 siblings, 1 reply; 17+ messages in thread From: Stefano Stabellini @ 2015-10-14 13:04 UTC (permalink / raw) To: Wei Liu; +Cc: anthony.perard, xen-devel, Ian Campbell, 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 13:04 ` Stefano Stabellini @ 2015-10-14 13:24 ` Wei Liu 2015-10-14 13:35 ` Ian Campbell 0 siblings, 1 reply; 17+ messages in thread From: Wei Liu @ 2015-10-14 13:24 UTC (permalink / raw) To: Stefano Stabellini; +Cc: anthony.perard, xen-devel, Wei Liu, Ian Campbell 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 13:24 ` Wei Liu @ 2015-10-14 13:35 ` Ian Campbell 2015-10-14 13:39 ` Wei Liu 2015-10-14 13:51 ` Stefano Stabellini 0 siblings, 2 replies; 17+ messages in thread From: Ian Campbell @ 2015-10-14 13:35 UTC (permalink / raw) To: Wei Liu, Stefano Stabellini; +Cc: anthony.perard, xen-devel 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 13:35 ` Ian Campbell @ 2015-10-14 13:39 ` Wei Liu 2015-10-14 13:51 ` Stefano Stabellini 1 sibling, 0 replies; 17+ messages in thread From: Wei Liu @ 2015-10-14 13:39 UTC (permalink / raw) To: Ian Campbell; +Cc: anthony.perard, xen-devel, Wei Liu, Stefano Stabellini 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 13:35 ` Ian Campbell 2015-10-14 13:39 ` Wei Liu @ 2015-10-14 13:51 ` Stefano Stabellini 2015-10-14 14:10 ` Ian Campbell 1 sibling, 1 reply; 17+ messages in thread From: Stefano Stabellini @ 2015-10-14 13:51 UTC (permalink / raw) To: Ian Campbell; +Cc: anthony.perard, xen-devel, Wei Liu, 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 13:51 ` Stefano Stabellini @ 2015-10-14 14:10 ` Ian Campbell 2015-10-14 14:11 ` Stefano Stabellini 0 siblings, 1 reply; 17+ messages in thread From: Ian Campbell @ 2015-10-14 14:10 UTC (permalink / raw) To: Stefano Stabellini; +Cc: anthony.perard, xen-devel, Wei Liu 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 14:10 ` Ian Campbell @ 2015-10-14 14:11 ` Stefano Stabellini 2015-10-14 14:25 ` Ian Campbell 0 siblings, 1 reply; 17+ messages in thread From: Stefano Stabellini @ 2015-10-14 14:11 UTC (permalink / raw) To: Ian Campbell; +Cc: anthony.perard, xen-devel, Wei Liu, 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 14:11 ` Stefano Stabellini @ 2015-10-14 14:25 ` Ian Campbell 0 siblings, 0 replies; 17+ messages in thread From: Ian Campbell @ 2015-10-14 14:25 UTC (permalink / raw) To: Stefano Stabellini; +Cc: anthony.perard, xen-devel, Wei Liu 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Xen 4.6, OVMF and arm64 2015-10-14 12:55 ` Stefano Stabellini 2015-10-14 13:04 ` Wei Liu @ 2015-10-14 13:05 ` Ian Campbell 1 sibling, 0 replies; 17+ messages in thread From: Ian Campbell @ 2015-10-14 13:05 UTC (permalink / raw) To: Stefano Stabellini; +Cc: anthony.perard, xen-devel, Wei Liu 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2015-10-14 14:25 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-10-14 11:25 Xen 4.6, OVMF and arm64 Stefano Stabellini 2015-10-14 11:29 ` Wei Liu 2015-10-14 11:30 ` Stefano Stabellini 2015-10-14 11:35 ` Wei Liu 2015-10-14 11:32 ` Wei Liu 2015-10-14 11:38 ` Ian Campbell 2015-10-14 12:55 ` Stefano Stabellini 2015-10-14 13:04 ` Wei Liu 2015-10-14 13:04 ` Stefano Stabellini 2015-10-14 13:24 ` Wei Liu 2015-10-14 13:35 ` Ian Campbell 2015-10-14 13:39 ` Wei Liu 2015-10-14 13:51 ` Stefano Stabellini 2015-10-14 14:10 ` Ian Campbell 2015-10-14 14:11 ` Stefano Stabellini 2015-10-14 14:25 ` Ian Campbell 2015-10-14 13:05 ` Ian Campbell
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.