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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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?

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

Ian.



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