From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: xen: arm: beginning the removal of mode_switch.S Date: Thu, 15 Aug 2013 14:46:10 +0100 Message-ID: <20130815134610.GB60836@ocelot.phlegethon.org> 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: Content-Disposition: inline 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: Julien Grall , Chen Baozi , Stefano Stabellini , xen-devel List-Id: xen-devel@lists.xenproject.org At 12:51 +0100 on 15 Aug (1376571083), Ian Campbell wrote: > 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) Sorry, I'm not quite clear -- do you plan to have this bootwrapper handle the spinning CPUs, with a semihosting callback from Xen to release them? That sounds pretty good. > 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 certainly like the look of the xen-side patch :) The bootloader looks broadly good to me, including all the kconfig stuff. Do you think we'd maintain that in xen.org or upstream? Cheers, Tim.