[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] Add minimal Vexpress Cortex A15 support
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [PATCH] Add minimal Vexpress Cortex A15 support |
Date: |
Tue, 06 Dec 2011 14:39:16 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 |
On 12/06/2011 02:35 PM, Peter Maydell wrote:
> On 6 December 2011 12:28, Avi Kivity <address@hidden> wrote:
> > On 12/01/2011 03:37 AM, address@hidden 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