From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56901) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXuJ5-0003DF-2Q for qemu-devel@nongnu.org; Tue, 06 Dec 2011 07:39:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXuJ1-0007Al-1L for qemu-devel@nongnu.org; Tue, 06 Dec 2011 07:39:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:14456) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXuJ0-0007Af-Lf for qemu-devel@nongnu.org; Tue, 06 Dec 2011 07:39:30 -0500 Message-ID: <4EDE0CF4.4070503@redhat.com> Date: Tue, 06 Dec 2011 14:39:16 +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> 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:35 PM, Peter Maydell wrote: > On 6 December 2011 12:28, Avi Kivity wrote: > > On 12/01/2011 03:37 AM, bill4carson@gmail.com wrote: > >> + /* ??? Hack to map an additional page of ram for the secondary CPU > >> + startup code. I guess this works on real hardware because the > >> + BootROM happens to be in ROM/flash or in memory that isn't clobbered > >> + until after Linux boots the secondary CPUs. */ > >> + ram_offset = qemu_ram_alloc(NULL, "vexpress.hack", 0x1000); > >> + cpu_register_physical_memory(SMP_BOOT_ADDR, 0x1000, > >> + ram_offset | IO_MEM_RAM); > > > It would be better to unhack this; short-term hacks tend to remain in > > the long term, and even after they're fixed we keep them for backwards > > compatibility. > > 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? > 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? -- error compiling committee.c: too many arguments to function