Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Dario Faggioli]

On Mon, 2017-09-25 at 01:31 -0600, Jan Beulich wrote:
> > > > On 22.09.17 at 19:20,  wrote:
> > 
> > Signed-off-by: Anthony PERARD 
> 
> Would you mind clarifying in a brief description whether this is just
> routine catch up, or to bring in any specific changes we need?
> 
What we have right now, does not build, e.g., with gcc 7.2:

https://pastebin.com/xgeJHkdL

Which, I agree, should be mentioned/hinted at in the changelog.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Jan Beulich]

>>> On 22.09.17 at 19:20,  wrote:
> Signed-off-by: Anthony PERARD 

Would you mind clarifying in a brief description whether this is just
routine catch up, or to bring in any specific changes we need?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Wei Liu]

On Mon, Nov 16, 2015 at 12:08:45PM +, Ian Campbell wrote:
> On Thu, 2015-11-12 at 10:06 +, Wei Liu wrote:
> > The new osstest tested head contains a fix for gcc-4.4 toolchain.
> > 
> > Signed-off-by: Wei Liu 
> > ---
> > Cc: "Hao, Xudong" 
> > Cc: Ian Campbell 
> > 
> > Please pull from
> >   git://xenbits.xen.org/osstest/ovmf.git xen-tested-master
> 
> For future such updates please could you use the specific commit here, so
> we avoid issues with osstest pushing something newer and I can just cut the
> line onto the end of a "git fetch".

NP. I will do that in the future.

> 
> I have done:
> 
> ianc@cosworth:edk2.git$ git fetch git://xenbits.xen.org/osstest/ovmf.git  
> 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
> From git://xenbits.xen.org/osstest/ovmf
>  * branch52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -> FETCH_HEAD
> ianc@cosworth:edk2.git$ git push maint --dry-run 
> 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d:master
> To ssh://xenbits.xen.org/home/xen/git/ovmf.git
>    af9785a..52a9949  52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -> master
> ianc@cosworth:edk2.git$ git push maint  
> 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d:master
> Counting objects: 1642, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (640/640), done.
> Writing objects: 100% (1642/1642), 2.43 MiB | 4.09 MiB/s, done.
> Total 1642 (delta 1080), reused 1544 (delta 992)
> To ssh://xenbits.xen.org/home/xen/git/ovmf.git
>    af9785a..52a9949  52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -> master
> 
> and acked + applied this patch.
> 

Thanks.

> > and push the said commit to
> >   git://xenbits.xen.org/ovmf.git master
> > 
> > It should be a fast-forward push.
> > ---
> >  Config.mk | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Config.mk b/Config.mk
> > index 5db7ca5..1392575 100644
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -253,7 +253,7 @@ QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xe
> > n-traditional.git
> >  SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
> >  MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
> >  endif
> > -OVMF_UPSTREAM_REVISION ?= af9785a9ed61daea52b47f0bf448f1f228beee1e
> > +OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
> >  QEMU_UPSTREAM_REVISION ?= master
> >  MINIOS_UPSTREAM_REVISION ?= 256035e01a1aa5739e34f245f3b1e9e8ee204210
> >  # Thu Jul 23 11:08:38 2015 +0100

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Ian Campbell]

On Thu, 2015-11-12 at 10:06 +, Wei Liu wrote:
> The new osstest tested head contains a fix for gcc-4.4 toolchain.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: "Hao, Xudong" 
> Cc: Ian Campbell 
> 
> Please pull from
>   git://xenbits.xen.org/osstest/ovmf.git xen-tested-master

For future such updates please could you use the specific commit here, so
we avoid issues with osstest pushing something newer and I can just cut the
line onto the end of a "git fetch".

I have done:

ianc@cosworth:edk2.git$ git fetch git://xenbits.xen.org/osstest/ovmf.git  
52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
From git://xenbits.xen.org/osstest/ovmf
 * branch52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -> FETCH_HEAD
ianc@cosworth:edk2.git$ git push maint --dry-run 
52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d:master
To ssh://xenbits.xen.org/home/xen/git/ovmf.git
   af9785a..52a9949  52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -> master
ianc@cosworth:edk2.git$ git push maint  
52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d:master
Counting objects: 1642, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (640/640), done.
Writing objects: 100% (1642/1642), 2.43 MiB | 4.09 MiB/s, done.
Total 1642 (delta 1080), reused 1544 (delta 992)
To ssh://xenbits.xen.org/home/xen/git/ovmf.git
   af9785a..52a9949  52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -> master

and acked + applied this patch.

> and push the said commit to
>   git://xenbits.xen.org/ovmf.git master
> 
> It should be a fast-forward push.
> ---
>  Config.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Config.mk b/Config.mk
> index 5db7ca5..1392575 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -253,7 +253,7 @@ QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xe
> n-traditional.git
>  SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
>  MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
>  endif
> -OVMF_UPSTREAM_REVISION ?= af9785a9ed61daea52b47f0bf448f1f228beee1e
> +OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
>  QEMU_UPSTREAM_REVISION ?= master
>  MINIOS_UPSTREAM_REVISION ?= 256035e01a1aa5739e34f245f3b1e9e8ee204210
>  # Thu Jul 23 11:08:38 2015 +0100

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Ian Campbell]

On Fri, 2015-10-23 at 02:01 -0600, Jan Beulich wrote:
> > > > On 22.10.15 at 19:08,  wrote:
> > Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF
> > changeset"):
> > > On Thu, 22 Oct 2015, Ian Campbell wrote:
> > > > This was discussed prior to Wei submitting this patch, but I can't
> > > > remember
> > > > the reference. Hopefully either Wei or Stefano does.
> > > 
> > > 1444832748.23192.213.ca...@citrix.com 
> > 
> > Thanks for the reference.
> > 
> > I'm quite uncomfortable with this, really.
> > 
> > People who are using xen.git stable branches ought to get only changes
> > that we (or perhaps, someone else whose judgement we have some reason
> > to trust) have intentionally decided are suitable for deployment as a
> > bugfix or security update in an existing installation.
> > 
> > Ie, changes in stable branches are supposed to be low risk.  That's
> > not compatible with tracking an upstream development branch.
> 
> FWIW, I agree. Do we know of specific commits that we actually
> need?

Yes. Those (that?) and the reasons why we aren't just trivially taking them
are explained in the referenced thread.

Really this is about adding a new feature (arm64 support for ovmf) into
4.6.1 for Raisin's benefit.

My personal preference, given the arguments made in the thread, would be
for raisin to just point at mainline ovmf for the arm64 case. IOW
acknowledge that arm64 ovmf was not actually part of the 4.6 release and
that we should work towards making it not a special case in the 4.7 release
(by, you know, testing it prior to release and things like that).

IMHO the most natural way to express that would be to differentiate the
"OVMF blob built into hvmloader" from "OVMF consumed as an external
'kernel'" as different components in raisin and include them in the
appropriate per-parch component lists. While the former is something which
we test and include in our releases the latter is more akin to how grub2 is
(loosely) integrated.

Ian.



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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Stefano Stabellini]

On Fri, 23 Oct 2015, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF changeset"):
> > On Fri, 23 Oct 2015, Ian Campbell wrote:
> > > Yes. Those (that?) and the reasons why we aren't just trivially taking 
> > > them
> > > are explained in the referenced thread.
> 
> That explanation isn't very convincing to me.
> 
> > I cannot believe we are going to move forward without a way to introduce
> > any OVMF fixes into the  stable branches.
> 
> It is fine to introduce OVMF fixes into stable branches, of course.
> 
> But it is not fine to introduce other upstream changes to OVMF,
> willy-nilly.
> 
> Obviously these two requirements cannot be satisfied without there
> being some branch of OVMF which contains the intended fixes, without
> the unwanted upstream development.
> 
> If OVMF upstream do not have such a branch, we need to create one.

That's fine. We need the new branch in osstest and somebody maintaining
it.

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Stefano Stabellini]

On Fri, 23 Oct 2015, Ian Campbell wrote:
> On Fri, 2015-10-23 at 02:01 -0600, Jan Beulich wrote:
> > > > > On 22.10.15 at 19:08,  wrote:
> > > Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF
> > > changeset"):
> > > > On Thu, 22 Oct 2015, Ian Campbell wrote:
> > > > > This was discussed prior to Wei submitting this patch, but I can't
> > > > > remember
> > > > > the reference. Hopefully either Wei or Stefano does.
> > > > 
> > > > 1444832748.23192.213.ca...@citrix.com 
> > > 
> > > Thanks for the reference.
> > > 
> > > I'm quite uncomfortable with this, really.
> > > 
> > > People who are using xen.git stable branches ought to get only changes
> > > that we (or perhaps, someone else whose judgement we have some reason
> > > to trust) have intentionally decided are suitable for deployment as a
> > > bugfix or security update in an existing installation.
> > > 
> > > Ie, changes in stable branches are supposed to be low risk.  That's
> > > not compatible with tracking an upstream development branch.
> > 
> > FWIW, I agree. Do we know of specific commits that we actually
> > need?
> 
> Yes. Those (that?) and the reasons why we aren't just trivially taking them
> are explained in the referenced thread.
> 
> Really this is about adding a new feature (arm64 support for ovmf) into
> 4.6.1 for Raisin's benefit.

This is not just about Raisin. What's going to happen when we fix a bug
in OVMF (http://marc.info/?l=xen-devel=144552787020580) which we think
needs to be backport to 4.6?

I cannot believe we are going to move forward without a way to introduce
any OVMF fixes into the  stable branches.


> My personal preference, given the arguments made in the thread, would be
> for raisin to just point at mainline ovmf for the arm64 case. IOW
> acknowledge that arm64 ovmf was not actually part of the 4.6 release and
> that we should work towards making it not a special case in the 4.7 release
> (by, you know, testing it prior to release and things like that).

Let's now lose the focus of the conversation by talking about this
specific backport request. We can always find ways around this in
Raisin.

The real problem is: what are we going to do about backport requests for
OVMF in general?

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Fabio Fantoni]

Il 23/10/2015 14:56, Ian Campbell ha scritto:

On Fri, 2015-10-23 at 13:43 +0100, Stefano Stabellini wrote:

We have no existing stable baseline for that arch, and no testing or
reason to believe that cb9a7eb (the Config.mk version currently
referenced by 4.6) as being any good at all on that platform,
whether we backport a couple of fixes to it or not.

It is true that ovmf arm64 is not in osstest, but I ran the test
manually and I know that cb9a7eb plus the one backport works, which is
just a build fix. In addition the original work for arm64 support was
done far earlier than cb9a7eb.

20% of the patches since then are ARM related and I'm not sure that a quick
smoke test is a high enough bar to add something in a stable point release
(it might suffice for adding to the development branch and subsequently
releasing, after plenty of time and -rc's, test days etc)


I'm not convinced that taking some arbitrary old (although not as old
as I
thought) OVMF tree which we have tested to our satisfaction and
released on
x86, slapping a couple of arm64 backports on it and saying "this is now
a
good and stable thing to use on arm64" makes it good enough to release
as
ovmf arm64 in 4.6.1, encouraging our users to go about using etc.

Far better to be honest about it for now and point arm64 users at a
more
bleeding edge ovmf release outside of our own stable releases and
prepare
to do something better in 4.7.
  
Are you suggesting we don't create an OVMF branch for 4.6 until the

first backport request comes along which we think is appropriate, then
we decide what to do?  I would rather have an OVMF branch for 4.6 now,
even if it is just cb9a7eb with no backports.

I'm not against having an OVMF branch ready for any potential bug fixes
which might crop up in the feature set we released and in future we should
probably create one as a matter of course as part of branching.

What I don't like is adding OVMF/arm64 as a new feature in a point release
with very little of the usual confidence we would have in something we
would add in a 4.6.0, let alone a 4.6.1.

Ian.

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


A recent ovmf patch (already tested) I think is good to backport is:
0f34a051104e2b1b9123d56d48673de4b21bc533 - OvmfPkg: XenPvBlkDxe: handle 
empty cdrom drives
Can be considered please? Without any domU using ovmf and having empty 
cdrom (required for cd hotplug) freeze on boot start.


There is also another important occasional bug (reported and linked also 
by Stefano Stabellini) but without solution for now where is good 
backport any fixes related when will be done.


Thanks for any reply and sorry for my bad english.

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Ian Campbell]

On Fri, 2015-10-23 at 15:16 +0200, Fabio Fantoni wrote:
> A recent ovmf patch (already tested) I think is good to backport is:

Pointing out backport candidates in the depths of a thread such as this is
a sure fire way to ensure they get missed I'm afraid.

Please make such requests explicitly in a new thread, or at least in a
reply to the patch in question.

Ian.

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Stefano Stabellini]

On Fri, 23 Oct 2015, Ian Campbell wrote:
> On Fri, 2015-10-23 at 12:18 +0100, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF
> > changeset"):
> > > On Fri, 23 Oct 2015, Ian Campbell wrote:
> > > > Yes. Those (that?) and the reasons why we aren't just trivially
> > > > taking them
> > > > are explained in the referenced thread.
> > 
> > That explanation isn't very convincing to me.
> > 
> > > I cannot believe we are going to move forward without a way to
> > > introduce
> > > any OVMF fixes into the  stable branches.
> > 
> > It is fine to introduce OVMF fixes into stable branches, of course.
> > 
> > But it is not fine to introduce other upstream changes to OVMF,
> > willy-nilly.
> > 
> > Obviously these two requirements cannot be satisfied without there
> > being some branch of OVMF which contains the intended fixes, without
> > the unwanted upstream development.
> 
> For things which we released as part of a stable release I completely
> agree.
>
> But OVMF for aarch64 was not part of the 4.6 release.

What I asked is only one of the backports that might present themselves
in the future. Even if the backport request is rejected, I think we
should create an OVMF branch for 4.6 anyway.


> We have no existing stable baseline for that arch, and no testing or
> reason to believe that cb9a7eb (the Config.mk version currently
> referenced by 4.6) as being any good at all on that platform,
> whether we backport a couple of fixes to it or not.

It is true that ovmf arm64 is not in osstest, but I ran the test
manually and I know that cb9a7eb plus the one backport works, which is
just a build fix. In addition the original work for arm64 support was
done far earlier than cb9a7eb.


> I'm not convinced that taking some arbitrary old (although not as old as I
> thought) OVMF tree which we have tested to our satisfaction and released on
> x86, slapping a couple of arm64 backports on it and saying "this is now a
> good and stable thing to use on arm64" makes it good enough to release as
> ovmf arm64 in 4.6.1, encouraging our users to go about using etc.
> 
> Far better to be honest about it for now and point arm64 users at a more
> bleeding edge ovmf release outside of our own stable releases and prepare
> to do something better in 4.7.
 
Are you suggesting we don't create an OVMF branch for 4.6 until the
first backport request comes along which we think is appropriate, then
we decide what to do?  I would rather have an OVMF branch for 4.6 now,
even if it is just cb9a7eb with no backports.

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Ian Jackson]

Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF changeset"):
> On Fri, 23 Oct 2015, Ian Campbell wrote:
> > Yes. Those (that?) and the reasons why we aren't just trivially taking them
> > are explained in the referenced thread.

That explanation isn't very convincing to me.

> I cannot believe we are going to move forward without a way to introduce
> any OVMF fixes into the  stable branches.

It is fine to introduce OVMF fixes into stable branches, of course.

But it is not fine to introduce other upstream changes to OVMF,
willy-nilly.

Obviously these two requirements cannot be satisfied without there
being some branch of OVMF which contains the intended fixes, without
the unwanted upstream development.

If OVMF upstream do not have such a branch, we need to create one.

Ian.

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Ian Jackson]

Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF changeset"):
> On Fri, 23 Oct 2015, Ian Jackson wrote:
> > If OVMF upstream do not have such a branch, we need to create one.
> 
> That's fine. We need the new branch in osstest and somebody maintaining
> it.

Creating a push gate in osstest is easy.  I'm happy to do that.

Whoever knows what OVMF fixes need to be cherrypicked should be in
charge of the branch.

Ian.

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Jan Beulich]

>>> On 23.10.15 at 13:18,  wrote:
> Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF changeset"):
>> On Fri, 23 Oct 2015, Ian Campbell wrote:
>> > Yes. Those (that?) and the reasons why we aren't just trivially taking them
>> > are explained in the referenced thread.
> 
> That explanation isn't very convincing to me.
> 
>> I cannot believe we are going to move forward without a way to introduce
>> any OVMF fixes into the  stable branches.
> 
> It is fine to introduce OVMF fixes into stable branches, of course.
> 
> But it is not fine to introduce other upstream changes to OVMF,
> willy-nilly.
> 
> Obviously these two requirements cannot be satisfied without there
> being some branch of OVMF which contains the intended fixes, without
> the unwanted upstream development.
> 
> If OVMF upstream do not have such a branch, we need to create one.

Or, if we're mainly concerned about in-tree builds, we need to apply
patches just like we do for e.g. ipxe.

Jan


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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Ian Campbell]

On Fri, 2015-10-23 at 12:18 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF
> changeset"):
> > On Fri, 23 Oct 2015, Ian Campbell wrote:
> > > Yes. Those (that?) and the reasons why we aren't just trivially
> > > taking them
> > > are explained in the referenced thread.
> 
> That explanation isn't very convincing to me.
> 
> > I cannot believe we are going to move forward without a way to
> > introduce
> > any OVMF fixes into the  stable branches.
> 
> It is fine to introduce OVMF fixes into stable branches, of course.
> 
> But it is not fine to introduce other upstream changes to OVMF,
> willy-nilly.
> 
> Obviously these two requirements cannot be satisfied without there
> being some branch of OVMF which contains the intended fixes, without
> the unwanted upstream development.

For things which we released as part of a stable release I completely
agree.

But OVMF for aarch64 was not part of the 4.6 release. We have no existing
stable baseline for that arch, and no testing or reason to believe that
cb9a7eb (the Config.mk version currently referenced by 4.6) as being any
good at all on that platform, whether we backport a couple of fixes to it
or not.

I'm not convinced that taking some arbitrary old (although not as old as I
thought) OVMF tree which we have tested to our satisfaction and released on
x86, slapping a couple of arm64 backports on it and saying "this is now a
good and stable thing to use on arm64" makes it good enough to release as
ovmf arm64 in 4.6.1, encouraging our users to go about using etc.

Far better to be honest about it for now and point arm64 users at a more
bleeding edge ovmf release outside of our own stable releases and prepare
to do something better in 4.7.

> If OVMF upstream do not have such a branch, we need to create one.

Ian.

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Jan Beulich]

>>> On 22.10.15 at 19:08,  wrote:
> Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF changeset"):
>> On Thu, 22 Oct 2015, Ian Campbell wrote:
>> > This was discussed prior to Wei submitting this patch, but I can't remember
>> > the reference. Hopefully either Wei or Stefano does.
>> 
>> 1444832748.23192.213.ca...@citrix.com 
> 
> Thanks for the reference.
> 
> I'm quite uncomfortable with this, really.
> 
> People who are using xen.git stable branches ought to get only changes
> that we (or perhaps, someone else whose judgement we have some reason
> to trust) have intentionally decided are suitable for deployment as a
> bugfix or security update in an existing installation.
> 
> Ie, changes in stable branches are supposed to be low risk.  That's
> not compatible with tracking an upstream development branch.

FWIW, I agree. Do we know of specific commits that we actually
need?

Jan


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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Ian Campbell]

On Wed, 2015-10-14 at 12:41 +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu 

Acked + applied.

Ian, I beleive Stefano would like to see this in 4.6 at some point.

> ---
> Please pull from
> 
>   git://xenbits.xen.org/osstest/ovmf.git xen-tested-master
> 
> and push the aforementioned commit to
> 
>   git://xenbits.xen.org/ovmf.git master
> 
> It should be a fast-forward push.

I did:

$ git push ssh://xenbits.xen.org/home/xen/git/ovmf.git 
af9785a9ed61daea52b47f0bf448f1f228beee1e:master
Counting objects: 6164, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (1991/1991), done.
Writing objects: 100% (6164/6164), 4.36 MiB | 1.09 MiB/s, done.
Total 6164 (delta 4760), reused 5443 (delta 4127)
To ssh://xenbits.xen.org/home/xen/git/ovmf.git
   cb9a7eb..af9785a  af9785a9ed61daea52b47f0bf448f1f228beee1e -> master

Which I think is as intended.

> ---
>  Config.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Config.mk b/Config.mk
> index 0e5b51b..143b0b0 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -253,7 +253,7 @@ QEMU_TRADITIONAL_URL ?= git
> ://xenbits.xen.org/qemu-xen-unstable.git
>  SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
>  MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
>  endif
> -OVMF_UPSTREAM_REVISION ?= cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd
> +OVMF_UPSTREAM_REVISION ?= af9785a9ed61daea52b47f0bf448f1f228beee1e
>  QEMU_UPSTREAM_REVISION ?= master
>  MINIOS_UPSTREAM_REVISION ?= 256035e01a1aa5739e34f245f3b1e9e8ee204210
>  # Thu Jul 23 11:08:38 2015 +0100

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Wei Liu]

On Thu, Oct 22, 2015 at 04:58:52PM +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH] Config.mk: update OVMF changeset"):
> > On Wed, 2015-10-14 at 12:41 +0100, Wei Liu wrote:
> > > Signed-off-by: Wei Liu 
> > 
> > Acked + applied.
> > 
> > Ian, I beleive Stefano would like to see this in 4.6 at some point.
> ...
> > To ssh://xenbits.xen.org/home/xen/git/ovmf.git
> >cb9a7eb..af9785a  af9785a9ed61daea52b47f0bf448f1f228beee1e -> master
> 
> This pulls in 782 commits.  That's hardly desirable for a stable
> release, surely ?  Does OVMF not have a stable branch ?
> 

No, upstream doesn't have stable branch. And we don't have our own
stable branch at the moment due to upstream doesn't make release or
maintain stable branch.

Currently the only method to see upstream changes ended in our stable
branch is to make backport request like this.

Wei.

> Ian.

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Ian Campbell]

On Thu, 2015-10-22 at 16:58 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH] Config.mk: update OVMF changeset"):
> > On Wed, 2015-10-14 at 12:41 +0100, Wei Liu wrote:
> > > Signed-off-by: Wei Liu 
> > 
> > Acked + applied.
> > 
> > Ian, I beleive Stefano would like to see this in 4.6 at some point.
> ...
> > To ssh://xenbits.xen.org/home/xen/git/ovmf.git
> >cb9a7eb..af9785a  af9785a9ed61daea52b47f0bf448f1f228beee1e -> master
> 
> This pulls in 782 commits.  That's hardly desirable for a stable
> release, surely ?  Does OVMF not have a stable branch ?

No, it doesn't.

This was discussed prior to Wei submitting this patch, but I can't remember
the reference. Hopefully either Wei or Stefano does.

Ian.

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Stefano Stabellini]

On Thu, 22 Oct 2015, Ian Campbell wrote:
> On Thu, 2015-10-22 at 16:58 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [PATCH] Config.mk: update OVMF changeset"):
> > > On Wed, 2015-10-14 at 12:41 +0100, Wei Liu wrote:
> > > > Signed-off-by: Wei Liu 
> > > 
> > > Acked + applied.
> > > 
> > > Ian, I beleive Stefano would like to see this in 4.6 at some point.
> > ...
> > > To ssh://xenbits.xen.org/home/xen/git/ovmf.git
> > >cb9a7eb..af9785a  af9785a9ed61daea52b47f0bf448f1f228beee1e -> master
> > 
> > This pulls in 782 commits.  That's hardly desirable for a stable
> > release, surely ?  Does OVMF not have a stable branch ?
> 
> No, it doesn't.
> 
> This was discussed prior to Wei submitting this patch, but I can't remember
> the reference. Hopefully either Wei or Stefano does.

1444832748.23192.213.ca...@citrix.com

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Ian Jackson]

Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF changeset"):
> On Thu, 22 Oct 2015, Ian Campbell wrote:
> > This was discussed prior to Wei submitting this patch, but I can't remember
> > the reference. Hopefully either Wei or Stefano does.
> 
> 1444832748.23192.213.ca...@citrix.com

Thanks for the reference.

I'm quite uncomfortable with this, really.

People who are using xen.git stable branches ought to get only changes
that we (or perhaps, someone else whose judgement we have some reason
to trust) have intentionally decided are suitable for deployment as a
bugfix or security update in an existing installation.

Ie, changes in stable branches are supposed to be low risk.  That's
not compatible with tracking an upstream development branch.

Sorry,
Ian.

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