[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.