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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2015-10-23 at 02:01 -0600, Jan Beulich wrote:
> > > > On 22.10.15 at 19:08, <Ian.Jackson@xxxxxxxxxxxxx> 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@xxxxxxxxxx 
> > 
> > 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel