From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: xen: arm: beginning the removal of mode_switch.S Date: Fri, 16 Aug 2013 17:11:41 +0200 Message-ID: <520E412D.2090002@linaro.org> References: <1376567483.9273.153.camel@hastur.hellion.org.uk> <520D0A72.1070501@citrix.com> <1376599896.9273.219.camel@hastur.hellion.org.uk> <520DFAF8.3030408@citrix.com> <1376665472.12491.20.camel@hastur.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1376665472.12491.20.camel@hastur.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Julien Grall , Tim Deegan , Chen Baozi , Stefano Stabellini , xen-devel List-Id: xen-devel@lists.xenproject.org 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.