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

[Ian Campbell <ian.campbell@citrix.com>]

On Fri, 2013-08-16 at 11:12 +0100, Julien Grall wrote:
> On 08/15/2013 09:51 PM, Ian Campbell wrote:
> > On Thu, 2013-08-15 at 18:05 +0100, Julien Grall wrote:
> >> Adding Andre.
> > 
> > 
> > I think Andre's platform should be able to avoid bootwrapper completely,
> > they do sensible things with cpu bringup, boot in NS HYP mode with
> > everything setup sensibly etc. This is the ideal situation of course,
> > with bootwrapper just being a last resort type thing.
> > 
> >> 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?
> > 
> > Yes, in cases where users can update u-boot or where vendors are
> > motivated to ship a system which works properly. Bootwrapper is only a
> > workaround for cases where this isn't possible
> > 
> > It is my intention that bootwrapper become a thing which you expect to
> > have to use with Xen always -- we should always strive to make the
> > firmware Just Work and only fallback to bootwrapper  where that isn't
> > possible for some reason.
> 
> Thanks for your answer !
> The bootwrapper can be avoid for the Arndale. I have noticed that if
> kick cpus is moved later, the secondary cpu will boot in HYP mode.

Excellent, so you are going to send a patch to nuke the relevant bits of
mode_switch.S?

> Otherwise I will give a try to the bootwrapper on the Versatile Express.

Andre seemed to suggest he had fixed (or was fixing) vexpress's u-boot
too, which only really leaves the models. I'd love to be able to run
u-boot there too simply for consistency...

I'd be happy if bootwrapper died before it even left the starting
line ;-) So long as we can nuke mode_switch.S...

Ian.