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

[Andre Przywara <andre.przywara@xxxxxxxxxx>]

On 08/16/2013 05:04 PM, Ian Campbell wrote:
> 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 managed to start Xen on the VExpress via my HYP-u-boot before. Only 
today I couldn't reproduce it with the latest bits...
Will see if I find the culprit.

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

Andre.


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