[PATCH] Config.mk: update OVMF changeset

[PATCH] Config.mk: update OVMF changeset

[Wei Liu]

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
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.
---
 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
-- 
2.1.4

Re: [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 <wei.liu2@citrix.com>

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

Re: [PATCH] Config.mk: update OVMF changeset

[Ian Jackson]

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 <wei.liu2@citrix.com>
> 
> 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 ?

Ian.

Re: [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 <wei.liu2@citrix.com>
> > 
> > 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.

Re: [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 <wei.liu2@citrix.com>
> > 
> > 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.

Re: [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 <wei.liu2@citrix.com>
> > > 
> > > 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.camel@citrix.com

Re: [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.camel@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.

Re: [PATCH] Config.mk: update OVMF changeset

[Jan Beulich]

>>> On 22.10.15 at 19:08, <Ian.Jackson@eu.citrix.com> 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.camel@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

Re: [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, <Ian.Jackson@eu.citrix.com> 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.camel@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.

Re: [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, <Ian.Jackson@eu.citrix.com> 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.camel@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&m=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?

Re: [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.

Re: [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.

Re: [PATCH] Config.mk: update OVMF changeset

[Jan Beulich]

>>> On 23.10.15 at 13:18, <Ian.Jackson@eu.citrix.com> 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

Re: [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.

Re: [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.

Re: [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.

Re: [PATCH] Config.mk: update OVMF changeset

[Ian Campbell]

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.

Re: [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.

Re: [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.

[PATCH] Config.mk: update OVMF changeset

[Wei Liu]

Signed-off-by: Wei Liu <wl@xen.org>
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index 4093dcb9e366..3603cf4ca58d 100644
--- a/Config.mk
+++ b/Config.mk
@@ -244,7 +244,7 @@ QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xen-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 ?= 20d2e5a125e34fc8501026613a71549b2a1a3e54
+OVMF_UPSTREAM_REVISION ?= a3741780fe3535e19e02efa869a7cac481891129
 QEMU_UPSTREAM_REVISION ?= master
 MINIOS_UPSTREAM_REVISION ?= master
 
-- 
2.20.1

[PATCH] Config.mk: update OVMF changeset

[Anthony PERARD]

Simply catching up with upstream.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index 0e829bb364..aeb418adf6 100644
--- a/Config.mk
+++ b/Config.mk
@@ -274,7 +274,7 @@ QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xen-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 ?= 947f3737abf65fda63f3ffd97fddfa6986986868
+OVMF_UPSTREAM_REVISION ?= ef529e6ab7c31290a33045bb1f1837447cc0eb56
 QEMU_UPSTREAM_REVISION ?= master
 MINIOS_UPSTREAM_REVISION ?= 0b4b7897e08b967a09bed2028a79fabff82342dd
 
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH] Config.mk: update OVMF changeset

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 775 bytes --]

On Mon, 2017-09-25 at 01:31 -0600, Jan Beulich wrote:
> > > > On 22.09.17 at 19:20, <anthony.perard@citrix.com> wrote:
> > 
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> 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
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

Re: [PATCH] Config.mk: update OVMF changeset

[Jan Beulich]

>>> On 22.09.17 at 19:20, <anthony.perard@citrix.com> wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

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

[PATCH] Config.mk: update OVMF changeset

[Anthony PERARD]

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index bba81bee7d..57d3e2bc44 100644
--- a/Config.mk
+++ b/Config.mk
@@ -272,7 +272,7 @@ QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xen-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 ?= 5920a9d16b1ab887c2858224316a98e961d71b05
+OVMF_UPSTREAM_REVISION ?= 947f3737abf65fda63f3ffd97fddfa6986986868
 QEMU_UPSTREAM_REVISION ?= master
 MINIOS_UPSTREAM_REVISION ?= d991bdbc062248221511ecb795617c36b37e1d2e
 # Wed Aug 9 13:15:48 2017 +0100
-- 
Anthony PERARD


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

[PATCH] Config.mk: update OVMF changeset

[Anthony PERARD]

This new changeset contain a fix to build with GCC 6.3.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index f0ca9e9379..7a0f94b2f2 100644
--- a/Config.mk
+++ b/Config.mk
@@ -267,7 +267,7 @@ QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xen-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 ?= 5734d486b6aa0b69a39b2c8d52b355400bcf2551
+OVMF_UPSTREAM_REVISION ?= 5920a9d16b1ab887c2858224316a98e961d71b05
 QEMU_UPSTREAM_REVISION ?= master
 MINIOS_UPSTREAM_REVISION ?= ca013fa9baf92f47469ba1f2e1aaa31c41d8a0bb
 # Tue Dec 13 15:02:02 2016 +0000
-- 
Anthony PERARD


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

Re: [PATCH] Config.mk: update OVMF changeset

[Wei Liu]

On Mon, Nov 16, 2015 at 12:08:45PM +0000, Ian Campbell wrote:
> On Thu, 2015-11-12 at 10:06 +0000, Wei Liu wrote:
> > The new osstest tested head contains a fix for gcc-4.4 toolchain.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> > Cc: "Hao, Xudong" <xudong.hao@intel.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > 
> > 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
>  * branch            52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -> 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

Re: [PATCH] Config.mk: update OVMF changeset

[Ian Campbell]

On Thu, 2015-11-12 at 10:06 +0000, Wei Liu wrote:
> The new osstest tested head contains a fix for gcc-4.4 toolchain.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
> Cc: "Hao, Xudong" <xudong.hao@intel.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> 
> 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
 * branch            52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -> 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

[PATCH] Config.mk: update OVMF changeset

[Wei Liu]

The new osstest tested head contains a fix for gcc-4.4 toolchain.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
Cc: "Hao, Xudong" <xudong.hao@intel.com>
Cc: Ian Campbell <ian.campbell@citrix.com>

Please pull from
  git://xenbits.xen.org/osstest/ovmf.git xen-tested-master
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-xen-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
-- 
2.1.4

Re: [PATCH] Config.mk: update OVMF changeset

[Ian Campbell]

On Mon, 2013-12-09 at 11:17 +0000, George Dunlap wrote:
> On 12/09/2013 11:10 AM, Wei Liu wrote:
> > On Mon, Dec 09, 2013 at 11:04:23AM +0000, George Dunlap wrote:
> >> On 12/08/2013 08:50 PM, Wei Liu wrote:
> >>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> >>> Cc: Ian Campbell <ian.campbell@citrix.com>
> >>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >>> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> >> This lacks a description of what the effect will be of updating to
> >> this changeset.  I'm guessing that the OVMF side of your recent
> >> fixes have gotten checked in?
> >>
> > Yes, necessary patches to integrate OVMF with Xen is upstreamed now.
> >
> > The original changeset in Config.mk:
> > 1. doesn't work with guest > 4G ram
> > 2. messes up PCI resource mapping
> >
> > The version of OVMF fixes those bugs and works well for me.
> 
> re the interface, we generally plan on building OVMF ourselves, right?  
> I don't think the interface between Xen and OVMF necessarily needs to be 
> stable at this point.
> 
> In any case, the interface changes are already in Xen; this doesn't make 
> the interface available, it just makes it easier for people to build OVMF.
> 
> Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>

acked + applied. Also pushed the requested update to ovmf.git.

For now I have held off on applying the patch which enables OVMF by
default ("tools: enable OVMF build for Linux by default"). I think that
deserves its own Release ack/nack.

Ian.

Re: [PATCH] Config.mk: update OVMF changeset

[Ian Campbell]

On Mon, 2013-12-09 at 11:17 +0000, George Dunlap wrote:
> On 12/09/2013 11:10 AM, Wei Liu wrote:
> > On Mon, Dec 09, 2013 at 11:04:23AM +0000, George Dunlap wrote:
> >> On 12/08/2013 08:50 PM, Wei Liu wrote:
> >>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> >>> Cc: Ian Campbell <ian.campbell@citrix.com>
> >>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >>> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> >> This lacks a description of what the effect will be of updating to
> >> this changeset.  I'm guessing that the OVMF side of your recent
> >> fixes have gotten checked in?
> >>
> > Yes, necessary patches to integrate OVMF with Xen is upstreamed now.
> >
> > The original changeset in Config.mk:
> > 1. doesn't work with guest > 4G ram
> > 2. messes up PCI resource mapping
> >
> > The version of OVMF fixes those bugs and works well for me.
> 
> re the interface, we generally plan on building OVMF ourselves, right?  
> I don't think the interface between Xen and OVMF necessarily needs to be 
> stable at this point.

It is an ABI between Xen and an external 3rd party codebase. Although we
might build it ourselves by default we cannot enforce this, and our
users might use e.g. their distro binary. This is similar to the
situation with upstream qemu.

This ABI absolutely has to be stable from now on (or make use of the
inbuilt capability to extend itself).

I don't think there is going to be any reason for this interface to
change so this is fine.

> In any case, the interface changes are already in Xen; this doesn't make 
> the interface available, it just makes it easier for people to build OVMF.
> 
> Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Re: [PATCH] Config.mk: update OVMF changeset

[George Dunlap]

On 12/09/2013 11:10 AM, Wei Liu wrote:
> On Mon, Dec 09, 2013 at 11:04:23AM +0000, George Dunlap wrote:
>> On 12/08/2013 08:50 PM, Wei Liu wrote:
>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>>> Cc: Ian Campbell <ian.campbell@citrix.com>
>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>>> Cc: George Dunlap <george.dunlap@eu.citrix.com>
>> This lacks a description of what the effect will be of updating to
>> this changeset.  I'm guessing that the OVMF side of your recent
>> fixes have gotten checked in?
>>
> Yes, necessary patches to integrate OVMF with Xen is upstreamed now.
>
> The original changeset in Config.mk:
> 1. doesn't work with guest > 4G ram
> 2. messes up PCI resource mapping
>
> The version of OVMF fixes those bugs and works well for me.

re the interface, we generally plan on building OVMF ourselves, right?  
I don't think the interface between Xen and OVMF necessarily needs to be 
stable at this point.

In any case, the interface changes are already in Xen; this doesn't make 
the interface available, it just makes it easier for people to build OVMF.

Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Re: [PATCH] Config.mk: update OVMF changeset

[Wei Liu]

On Mon, Dec 09, 2013 at 11:04:23AM +0000, George Dunlap wrote:
> On 12/08/2013 08:50 PM, Wei Liu wrote:
> >Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> >Cc: Ian Campbell <ian.campbell@citrix.com>
> >Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >Cc: George Dunlap <george.dunlap@eu.citrix.com>
> 
> This lacks a description of what the effect will be of updating to
> this changeset.  I'm guessing that the OVMF side of your recent
> fixes have gotten checked in?
> 

Yes, necessary patches to integrate OVMF with Xen is upstreamed now.

The original changeset in Config.mk:
1. doesn't work with guest > 4G ram
2. messes up PCI resource mapping

The version of OVMF fixes those bugs and works well for me.

Wei.

>  -George

Re: [PATCH] Config.mk: update OVMF changeset

[George Dunlap]

On 12/08/2013 08:50 PM, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>

This lacks a description of what the effect will be of updating to this 
changeset.  I'm guessing that the OVMF side of your recent fixes have 
gotten checked in?

  -George

[PATCH] Config.mk: update OVMF changeset

[Wei Liu]

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>

---
To IanC,

OVMF tree can be found at:
  http://xenbits.xen.org/git-http/people/liuw/ovmf.git for-xenbits
Please push that branch to Xenbits.

I presume that
   tools: enable OVMF build for Linux by default
is in your queue so I don't bother resending that. This patch should
probably go before that one.

To George,

Good: users can get their hands dirty with OVMF.
Bad : if somebody spots a problem in interface we have to live with it.

But, if nobody gets a chance to use it then nobody can spot a problem.
We've merged the interface in tree. I think the advantage of having OVMF
for 4.4 outweights the disadvantage. I suggest we let OVMF go in and
mark it as experimental.
---
 Config.mk |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index 7eeed31..9b5d1bd 100644
--- a/Config.mk
+++ b/Config.mk
@@ -233,7 +233,7 @@ OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git
 QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 endif
-OVMF_UPSTREAM_REVISION ?= a93b0e3f6895a074b99c8817181dfa6dbc7a4807
+OVMF_UPSTREAM_REVISION ?= 447d264115c476142f884af0be287622cd244423
 QEMU_UPSTREAM_REVISION ?= 1c514a7734b7f98625a0d18d5e8ee7581f26e50c
 SEABIOS_UPSTREAM_TAG ?= rel-1.7.3.1
 # Fri Aug 2 14:12:09 2013 -0400
-- 
1.7.10.4