[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Fri, 2012-10-26 at 12:18 +0100, Stefano Stabellini wrote:
> 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.

Isn't this controlled by the GICD_GROUP register, which can be set from
cpu0 but affects all cpus?

Or is it the case that we need to do this poke before mode_switch.S
makes all interrupts into grp1 interrupts?

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.