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: Thu, 15 Aug 2013 18:05:54 +0100 Message-ID: <520D0A72.1070501@citrix.com> References: <1376567483.9273.153.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: <1376567483.9273.153.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 Adding Andre. 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? -- Julien Grall