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

[Tim Deegan <tim@xxxxxxx>]

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.

> As we add new platforms I think we should first push back on the vendors
> to fix their firmware but when that turns out to not be possible we
> should move to patching this code with platform hacks instead of adding
> more stuff to mode_switch.S, IMO the only blocker to this is the
> kick_cpu support.
> 
> What does everyone think?

I certainly like the look of the xen-side patch :)

The bootloader looks broadly good to me, including all the kconfig
stuff.  Do you think we'd maintain that in xen.org or upstream?

Cheers,

Tim.

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