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

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 04/29/2013 11:33 AM, George Dunlap wrote:

> 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.


Most of the code modifies arch/arm and common/device_tree.c. There is
one patch which could impact x86 is "[RFC 17/29] xen/arm: New callback
in uart_driver to get device tree interrupt structure".

Julien

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