Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 26 Oct 2012, Ian Campbell wrote:
> 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?

Whether the target processor in secure mode receives the interrupt or
not, depends only on the GIC configuration on the target processor.
I don't think there is anything we can do from cpu0 in non-secure mode.


> Or are secondary CPUs actually spinning in secure supervisor mode?

Yes.


> 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.

That's right.


> > 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?
 
OK

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