From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH 5/7] xen/arm: wake up secondary cpus Date: Fri, 26 Oct 2012 08:30:18 +0100 Message-ID: <1351236618.8558.4.camel@dagon.hellion.org.uk> References: <1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com> <1351159160.18035.147.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" , "Tim (Xen.org)" List-Id: xen-devel@lists.xenproject.org On Thu, 2012-10-25 at 18:45 +0100, Stefano Stabellini wrote: > > > > > > boot_cpu: > > > @@ -98,6 +98,10 @@ boot_cpu: > > > PRINT(" booting -\r\n") > > > #endif > > > > > > + /* Wake up secondary cpus */ > > > + teq r12, #0 > > > + bleq kick_cpus > > > > Does this have to be done this early? Couldn't we defer it to C land > > where it would be easier to isolate the processor/platform specific > > behaviour? > > Yes, it does because we need to send an interrupt to cpus running in > secure mode, so this has to happen before we drop off secure state and we > enter hypervisor state. Hrm, so maybe this stuff does belong in mode_switch.S after all? Or is there perhaps some register (e.g. in the GIC?) which would allow non-secure hyp mode to sent an event to a processor in secure monitor mode? Or are secondary CPUs actually spinning in secure supervisor mode? I guess this works in Linux because the boot CPU is in *secure* kernel mode and that is allowed to send events to other secure modes? That's a further argument that this is related to the firmware not bringing us up in Hyp / NS mode and therefore that the fix should be in mode_switch.S. > > > /* Check that this CPU has Hyp mode */ > > > mrc CP32(r0, ID_PFR1) > > > and r0, r0, #0xf000 /* Bits 12-15 define virt extensions */ > > > diff --git a/xen/arch/arm/mode_switch.S b/xen/arch/arm/mode_switch.S > > > index 83a682b..39d80e8 100644 > > > --- a/xen/arch/arm/mode_switch.S > > > +++ b/xen/arch/arm/mode_switch.S > > > @@ -21,6 +21,37 @@ > > > #include > > > #include > > > > > > +/* XXX: Versatile Express specific code */ > > > +/* wake up secondary cpus */ > > > +.globl kick_cpus > > > +kick_cpus: > > > > My understanding was the mode_switch.S was intended to be a place to > > hold the hacks and fixups required because there is no firmware on the > > models and/or to address short comings in the firmware. This kick > > function is a normal/expected part of booting on a vexpress so I don't > > think it especially belongs here. > > I have created a processor.S file for processor specific initializations > (see ACTLR), maybe I can move it there. proc-ca15.S perhaps? So we can add proc-exynos.S etc in the future? Ian