Re: xen: arm: beginning the removal of mode_switch.S

[Julien Grall <julien.grall@citrix.com>]

Adding Andre.

On 08/15/2013 12:51 PM, Ian Campbell wrote:
> I did some hacking on boot-wrapper.git on the train to debconf and made
> it support building a zImage container encapsulating Xen+Linux+initramfs
> +fdt. Xen is optional so it can be used to boot natively too.
> 
> You can find the code in the multiplatform branch of
> http://xenbits.xen.org/gitweb/?p=people/ianc/boot-wrapper.git
> 
> It has build time (Kconfig driven) options to support:
>       * cubieboard2 (boots native ok, weird issue under Xen)
>       * arndale (code taken from existing mode switch.S, untested)
>       * vexpress and fastmodel (untested)
> 
> The code is pretty hacked up from the original (which only really
> supported fastmodels, and had limited configurability) and it could
> certainly be structured to be quite a bit cleaner (plus I think I got a
> bit carried away with using Kconfig for everything). I'd rather have
> some skanky hacked up code here than in Xen though, so I think this is
> an acceptable level of hackedupness. 
> 
> 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)
> 
> I might have time for this on the train on the way home, but since my
> cubieboard2 can't do SMP yet (even on native Linux, bringup looks
> complex) I suppose that means I need to test and debug the fastmodel
> support first...
> 
> 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'm not sure it's related... does this patch series
(https://lists.cs.columbia.edu/pipermail/kvmarm/2013-April/005581.html)
can avoid the bootwrapper code?

-- 
Julien Grall