Re: [Xen-devel] [RFC 00/29] Support multiple ARM platforms in Xen

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 29/04/13 11:17, Ian Campbell wrote:
> CCing George, Xen 4.3 release manager.
>
> On Mon, 2013-04-29 at 00:01 +0100, Julien Grall wrote:
> > Hello,
> >
> > This patch series is divided in 4 parts:
> >      - Patch 1-6: Minor bug fixes
> >      - Patch 7-10: Add hierarchical device tree support based on linux tree
> >      - Patch 11-24: Remove harcoded part
> >      - Patch 25-28: Arndale support based on Anthony's git
> >
> > Xen can boot on both Arndale Board and the Versatile Express without
> > recompilation. But there is still some hardcoded part, mainly in assembly.
> I haven't reviewed this yet but I think this is something we are going
> to want for the Xen 4.3 release if at all possible. (NB, for Linaro
> chaps, we are past feature and code freeze and are intending to release
> 4.3-rc1 next Monday, but there is scope for freeze exceptions to be
> argued for)
>
> Arndale is currently the only widely available/reasonably priced
> development platform which can run Xen and therefore IMHO Xen 4.3 needs
> to be able to run on it if it is to be a useful "tech preview" platform.
>
> The current xen.git tree runs on the vexpress platform (rather
> expensive) with the TC2 chip (difficult if not impossible for random
> developers to get hold of) and the software models (random developers
> can get an eval license for these, but they don't last very long). IMHO
> the priority order of the platforms for 4.3 is, in decreasing order:
>          Arndale
>          Fast Models
>          Vexpress
> (with vexpress there running a pretty distant third)
>
> Obviously there is a risk with these patches of breaking Xen on one or
> more (or all) of those platforms: I think this is a risk we should take.
>
> However this is not worth slipping the Xen release for, in particular it
> is not reasonable to delay the release for x86 users because we took a
> risk for a tech preview on ARM. So I propose that we take these patches
> and see how it goes. I think in practice the rc cycle will be plenty of
> time to sort out Xen on Arndale for 4.3, but the contingency plan would
> be to fix it up in 4.3.1 and/or maintain a brief xen-on-arm fork of 4.3.
Overall I want to defer the goals of the 4.3 ARM stuff to the ARM 
developers.  From this e-mail (and other IRL chats), it seems that there 
are a couple of possible outcomes:
1. Apply the current x86 code-freeze policy to ARM.  The result (IIUC) 
will be a 4.3 release will not support the Arndale boards.
2.  Relax the policy and allow this kind of patch series to be checked 
in.  Possible outcomes are:
2a. Arndale support will be stable by the scheduled 4.3 release
2b. Arndale support will not be stable by the scheduled release; we slip 
the release as a result
2c. Arndale support will not be stable by the scheduled release; we 
release anyway with "tech-preview-only" ARM support and fix it up in a 
subsequent minor point release 2-3 months afterwards.
I agree with Ian that 2b should be taken off the table.

So the choice now would be between choosing 1, or choosing the 
un-collapsed waveform {2a, 2c} (a la Schroedinger's cat).
Given that 2c is not really that much worse than 1, and 2a is much 
better than 1, I think from the ARM perspective it makes sense to accept 
the series.
The only other thing to consider is the potential impact on x86.  As 
long as any changes are highly likely to be detected before the 4.3 
release, I think it's OK: at a last resort we can just revert the change 
that introduced the bug.  The only thing we need to be careful of is not 
introducing bugs which have a risk of *not* being detected by the 4.3 
release.
So from a release perspective (assuming that there are no risky x86 
changes):
Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>

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