Re: [Xen-devel] xen: arm: beginning the removal of mode_switch.S

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2013-08-21 at 14:42 +0200, Andre Przywara wrote:
> On 08/21/2013 02:36 PM, Julien Grall wrote:
> > On 08/20/2013 03:11 PM, Ian Campbell wrote:
> >> So this is all pretty complex (not to mention hard to describe in ASCII)
> >> and in lockstep, the secondary cpus wait twice once on the original
> >> smp_cpu_up and then again on the relocated version. There is a subtle
> >> reliance on the 1:1 mapping being retained in the original copy of the
> >> page tables.
> >
> > Thanks for this ASCII!
> >
> >> I think the original wait is actually a workaround for lack of firmware
> >> on the fastmodels, and should be implemented by either the firmware or
> >> bootwrapper.
> >
> > BTW, this wait is an issue when the boot CPU ID is not equal to 0.
> >
> > I gave a quick try to move kick cpus after the HYP mode switch in
> > assembly and I'm unable to boot secondary cpus on the Versatile Express.
> > I guess, on the VE secondary cpus can only be "kick" in secure mode.
> 
> Right, but I think this is not specific to the VE, but ARM in general.
> If I remember correctly the reason was that you cannot send IPIs from an 
> non-secure GIC CPU interface to a secure one. So you have to enable the 
> CPU interfaces of the others cores for non-secure operation first, which 
> involves waking them up.
> In my U-Boot code I switch to HYP mode on the BSP at the very end, after 
> having switched the secondary cores to HYP before.

Yes, this is IMHO the right thing to do, firmware which launches the
boot cpu in a mode which cannot kick the other cpus is buggy.

Firmware which launches the boot CPU in NS mode but leaves secondary
CPUs in S world, without leaving some sort of channel (e.g PSCI) to wake
them is irrevocably buggy unfortunately, we cannot support those systems
unless the firmware can be updated.

At least if the firmware launches everything in secure world then u-boot
can fix it.

Ian.


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