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

[Julien Grall <julien.grall@linaro.org>]

On 09/18/2013 08:24 PM, Ian Campbell wrote:
> On Wed, 2013-09-18 at 20:22 +0100, Ian Campbell wrote:
>> On Wed, 2013-09-18 at 18:33 +0100, Julien Grall wrote:
>>> On 09/17/2013 02:37 AM, Ian Campbell wrote:
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>
>>> I have just tried the patch series on the versatile express and it
>>> doesn't work. I'm using the u-boot from Andre and all the cpus already
>>> boot in hyp mode (checked without this patch series).
>>
>> :-(
>>
>> The code should essentially the same as the old kick cpus, but
>> reimplemented in C. The only difference I can spot is that the C version
>> is kicking a single CPU at a time while the ASM version is kicking
>> everyone at once. Does using send_SGI_allbutself instead work as a hack?
>>
>> Perhaps our idea of the CPUID is wrong or something? Your patches to
>> fixup the logical CPU id stuff might help?

I have found the issue, in send_SGI_mask we remove the offline CPUs with 
the following line:
   mask &= cpumask_bits(&cpu_online_map);

As the secondary cpu (assuming we have a board with only 2 cores) is not 
yet online, we can't send SGI with our code.
I'm very surprised that the code works on the fast models.

To solve the issue, I think we need to create another helper which will 
send an SGI wihout removing offline CPUs.

> You don't happen to still have your vexpress in A7 mode do you?

I'm using the versatile express with only A15 processors enabled.

-- 
Julien Grall