From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXupF-0006ca-Vy for qemu-devel@nongnu.org; Tue, 06 Dec 2011 08:12:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXupA-0005I3-0N for qemu-devel@nongnu.org; Tue, 06 Dec 2011 08:12:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXup9-0005Hz-Q3 for qemu-devel@nongnu.org; Tue, 06 Dec 2011 08:12:43 -0500 Message-ID: <4EDE14BE.90208@redhat.com> Date: Tue, 06 Dec 2011 15:12:30 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1322703478-3292-1-git-send-email-bill4carson@gmail.com> <1322703478-3292-2-git-send-email-bill4carson@gmail.com> <4EDE0A53.2090903@redhat.com> <4EDE0CF4.4070503@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Add minimal Vexpress Cortex A15 support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: bill4carson@gmail.com, qemu-devel@nongnu.org, android-virt@lists.cs.columbia.edu On 12/06/2011 02:48 PM, Peter Maydell wrote: > On 6 December 2011 12:39, Avi Kivity wrote: > > On 12/06/2011 02:35 PM, Peter Maydell wrote: > >> On 6 December 2011 12:28, Avi Kivity wrote: > >> Do you have a better suggestion in this case? We've had the same > >> code in the realview board since 2007 when ARM SMP support was first > >> added... > > > > No idea really since I don't fully understand what's going on. It's > > just a knee-jerk reaction to the word 'hack'. > > > > Can't we just do what real hardware does? > > Real hardware runs the boot ROM. The boot ROM is an unredistributable > binary blob, and in any case we almost certainly don't implement > the hardware well enough to pass the boot ROM's self tests and init > code. > > We could probably put the pen code in a QEMU-specific bit of ROM > code in the same place the hardware boot ROM actually lives. That would be an improvement. > Longer term, I'm toying with the idea of having QEMU run UEFI > (for vexpress UEFI can boot the platform from bare metal, and it's > open source so we can (a) redistribute it and (b) add in qemu-specific > code if we need to). That would look a bit more like x86 qemu. Right. > >> There's no particular back-compat implication here as far as I know: > >> the location of the secondary CPU holding pen code is irrelevant to > >> the actual guest being run. (On a real system it will be somewhere > >> inside the boot ROM.) > > > > Suppose you live migrate when the code is running there? > > Currently for ARM we permit changes which would break live migration, > because it's not supported to start with. Okay, so we should remove the hack before enabling live migration. In any case, I understand you currently have to boot with -kernel? That's even a stronger reason to fix this thing. > (Does migration copy across rom contents and sizes?) Contents, yes, sizes, no. -- error compiling committee.c: too many arguments to function