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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.

Ian.


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