[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]