Re: [Xen-devel] [PATCH RFC 0/N] xen: arm: rework early bring up

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 09/17/2013 01:43 PM, Ian Campbell wrote:
> On Tue, 2013-09-17 at 12:34 +0100, Julien Grall wrote:
>> Adding Andre,
> 
> Thanks, I meant to and forgot...
> 
>> On 09/17/2013 02:37 AM, Ian Campbell wrote:
>>> Hi,
>>
>> Hi,
>>
>>> The following reworks early bring up on ARM to use a separate set of
>>> boot pagetables. This simplifies things by avoiding the need to bring up
>>> all CPUs in lock step, which in turn allows us to do secondary CPU
>>> bringup in C code.
>>
>> Great ! I will give a try on different boards and see what happens.
> 
> Thanks.
> 
>>> Unfortunately the main bulk of this change is a single large patch which
>>> is hard to decompose any further since it is basically pulling on the
>>> thread and then knitting a new jumper from it.
>>
>> I think you can split the patch in:
>>    - Add the new platform callback
>>    - Fast model SMP code
>>    - ...
>>
>> We will have dead code for "few" commit in Xen, but it will be easier to 
>> read the patch series :).
> 
> yes, that's a good idea. The main patch will still be massive though.
> 
>>> With these changes Xen now absolutely requires that the bootloader calls
>>> the hypervisor in HYP mode, the previous workarounds have been removed.
>>> For use on models a bootwrapper is now required. See
>>>          git://xenbits.xen.org/people/ianc/boot-wrapper.git xen-arm32
>>>          git://xenbits.xen.org/people/ianc/boot-wrapper-aarch64.git 
>>> xen-arm64
>>>
>>> I have implemented support for CPU bringup on the fastmodel vexpress
>>> platforms (v7and v8) here, I suppose it should work OK on a real
>>> vexpress too but I've not tried it.
>>
>> Unfortunately on the versatile express there is 2 different ways to 
>> bring up CPUs.
>> We can stick to this CPU bring up, as long as we ask the user to modify 
>> the board configuration.
> 
> Is it possible to determine programaticaly which method to use?

It seems no, I will take a closer look.

> In any case this series isn't changing anything in this regard, so we
> must already be asking users to modify the boards configuration.

-- 
Julien Grall

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