From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andre Przywara <andre.przywara@linaro.org>
Subject: Re: xen: arm: beginning the removal of mode_switch.S
Date: Wed, 21 Aug 2013 14:42:22 +0200
Message-ID: <5214B5AE.5040401@linaro.org>
References: <1376567483.9273.153.camel@hastur.hellion.org.uk>
	<520D0A72.1070501@citrix.com>
	<1376599896.9273.219.camel@hastur.hellion.org.uk>
	<520DFAF8.3030408@citrix.com>
	<1376665472.12491.20.camel@hastur.hellion.org.uk>
	<520E48DE.5080802@citrix.com>
	<1377007861.9517.52.camel@kazak.uk.xensource.com>
	<5214B43C.7090807@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <5214B43C.7090807@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Julien Grall <julien.grall@citrix.com>
Cc: Tim Deegan <tim@xen.org>, Chen Baozi <baozich@gmail.com>, Stefano Stabellini <stefano.stabellini@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

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.

Regards,
Andre.