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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2013-08-15 at 17:53 +0100, Tim Deegan wrote:
> At 15:07 +0100 on 15 Aug (1376579221), Ian Campbell wrote:
> > On Thu, 2013-08-15 at 14:46 +0100, Tim Deegan wrote:
> > > At 12:51 +0100 on 15 Aug (1376571083), Ian Campbell wrote:
> > > > At the moment it is sufficient to allow us to do away with the
> > > > enter_hyp_mode bits and the clock frequency, gic setup etc, along the
> > > > lines of the patch below.
> > > > 
> > > > It doesn't yet allow us to get rid of the kick_cpus stuff. My plan for
> > > > platforms which don't do the right thing here would be to add a
> > > > mechanism to use dtb /memreserve/ (and teach Xen about that construct)
> > > > to carve out a little bit of memory which secondary CPUs could safely be
> > > > left spinning in. The platform code would expose its normal interface
> > > > (e.g. SYS_FLAGS on vexpress and fastmodel), eventually maybe we'd do
> > > > PSCI too (which might let us skip reserving some memory since 2ndary
> > > > cpus would be in secure mode and could use the special ram regions
> > > > reserved for that)
> > > 
> > > Sorry, I'm not quite clear -- do you plan to have this bootwrapper
> > > handle the spinning CPUs, with a semihosting callback from Xen to
> > > release them?  That sounds pretty good.
> > 
> > Yes to spinning, no to semihosting (that's model specific).
> > 
> > On vexpress native this would be handled by writing the start paddr to
> > SYS_FLAGS and doing a "sev", which will wake up the secondaries (which
> > are spinning doing wfe) and cause them to jump to that address, so I
> > would expect the wrapper to implement the same but spinning in NS HYP
> > mode instead -- in fact the code is there already but I haven't tried it
> > (bet its broken).
> > 
> > Other platforms have similar mechanisms and I would expect the
> > bootwrapper to do something similar and mimic whatever the mechanism is
> > in NS HYP mode.
> 
> Ah, OK.  And the release code is in C in xen so it can be a
> model-specific routine that knows how the bootwrapper has set things up?

Yes, it would be a platform hook called from around __cpu_up.

My hope is that bootwrapper can mimic the underlying firmwares behaviour
but in non-secure instead of secure mode, so that the bringup code is
the same, and if the firmware is fixed then Xen doesn't need to change
or be aware of bootwrapper vs. non-bootwrapper etc.

Ian


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