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

[Christoffer Dall <christoffer.dall@xxxxxxxxxx>]

On Thu, Aug 15, 2013 at 10:55:35PM +0200, Andre Przywara wrote:
> On 08/15/2013 07:05 PM, Julien Grall wrote:
> >Adding Andre.
> 
> Thanks, Julien.
> CCing Christoffer for KVM point of view and boot-wrapper.git.
> Comments below.
> 
> >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?
> 
> Ian,
> 
> honestly I would not pursue any kind of secure mode / SMP / HYP mode
> switching inside Xen or a Xen related boot wrapper. This is actually
> task of the board's firmware, or bootloader if firmware does not do
> it for one or another reason.
> Naturally it should be the firmware's responsibility of doing this
> (like Calxeda does), if not there is now an "almost merged"(TM)
> u-boot implementation by me to solve at least the HYP mode / SMP
> switching:
> http://lists.denx.de/pipermail/u-boot/2013-August/160501.html
> This currently supports VExpress, I have Arndale support almost
> ready (still untested). Other boards should be easy to add as this
> was a design criteria of the patch set.
> 
> My next work item (next week's time frame) is to get some basic
> multiboot support into u-boot and Xen/ARM to allow the user to tell
> the bootloader which bits to load.
> 
> This is the approach Linaro agreed upon for Xen in July.
> 
> Alternatively I could teach u-boot to write the addresses in the DTB
> meeting your Xen code.
> 
> Wouldn't that solve all the problems you try to address with boot-wrapper?
> Since Linux/KVM requires the kernel to be entered in HYP mode
> anyway, Xen should be on the same page as them, so a joint effort
> would make sense here, right?
> 
> Honestly I'd like to do away with Xen's mode_switch.S as soon as
> possible. I tried to simply add Calxeda's native SMP kicking in
> there and failed, since the code actually reads:
> If r1 isn't the Arndale machine ID, assume Versatile Express :-(
> 
> We could either require PSCI support for boards supporting Xen or
> add platform specific SMP ops (boldly copying bits from Linux here).
> 
> >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?
> 
> That's the plan, but please see the v4 version posted last Friday
> (URL above).

FWIW, I second Andre's position; the boot-wrapper was simply a hack
before we had any proper bootloader support (like U-boot) on development
boards like the versatile express and it has been (ab)used for models as
well.  I'm not sure if boot-wrapper could be completely abandoned at
this point or if it is still needed for some cases (models, big.little,
...).  But surely anything we can reasonably do to leverage existing
U-boot work and do things the proper way will set the right example for
users and other implementors.

The latter perspective is especially important for Linaro as the whole
point of the organization is to work upstream and make things work
across many platforms.

-Christoffer

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