[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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?


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:
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
can avoid the bootwrapper code?

That's the plan, but please see the v4 version posted last Friday (URL above).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.