From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: xen: arm: beginning the removal of mode_switch.S Date: Fri, 16 Aug 2013 11:12:08 +0100 Message-ID: <520DFAF8.3030408@citrix.com> References: <1376567483.9273.153.camel@hastur.hellion.org.uk> <520D0A72.1070501@citrix.com> <1376599896.9273.219.camel@hastur.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1376599896.9273.219.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: Tim Deegan , Chen Baozi , Stefano Stabellini , Andre Przywara , xen-devel List-Id: xen-devel@lists.xenproject.org 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. Otherwise I will give a try to the bootwrapper on the Versatile Express. Cheers, -- Julien Grall