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

[Andre Przywara <andre.przywara@xxxxxxxxxx>]

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).
Thanks,
Andre.


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