Re: xen: arm: beginning the removal of mode_switch.S

[Ian Campbell <ian.campbell@citrix.com>]

On Thu, 2013-08-15 at 22:55 +0200, Andre Przywara wrote:
> 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.

That's great and as I've said a few times in this thread this is what we
should be aiming for, bootwrapper is not intended to replace or compete
with those patches, they are the right answer for sure.

> 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?

In an ideal world where vendors were responsive to bug reports and cared
enough to fix the virt use case, and where users feel confident enough
to replace the bootloader on the system etc etc then yes it absolutely
solves the problem and is exactly what people should be doing.

bootwrapper is there for the cases where the vendor doesn't care (about
virt, about Xen, etc), or people are unwilling to upgrade u-boot
(perhaps lack of JTAG makes bricking the system too much of a risk,
think random consumer devices), or maybe the vendor u-boot is too old or
too diverged from mainline to allow the patches to be applied without a
lot of development work. bootwrapper is a hack intended to allow people
to still run Xen on those platforms, it is not supposed to be
alternative to doing it properly.

I will happily delete platform code from bootwrapper the moment that a
fixed firmware/bootloader which can be deployed on a platform in a way
which end users can cope with is available. And I will certainly be
encouraging people to figure out how to do that rather than adding
platform support to bootwrapper.

> 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?

Yes. Xen's requirement is exactly the same as KVMs, we must be entered
in NS HYP mode. Bootwrapper is there to make this true in cases where it
otherwise is not and the firmware/bootloader cannot be fixed.

It's very good that you've fixed (or are fixing) the arndale and
vexpress stuff and have just done The Right Thing on Calxeda platforms
already.

With bootwrapper I'm more concerned about all the random cheap hardware
coming out of China (like the Allwinner derived stuff) which it might be
desirable for community members etc to run Xen on.

> Honestly I'd like to do away with Xen's mode_switch.S as soon as 
> possible.

Me too.

>  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 :-(

Right, it sucks. It's a hack and must die.

> We could either require PSCI support for boards supporting Xen or add 
> platform specific SMP ops (boldly copying bits from Linux here).

Yes, this is the plan.

Ian.