[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: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] Add minimal Vexpress Cortex A15 support
Date: Tue, 6 Dec 2011 12:48:07 +0000

On 6 December 2011 12:39, Avi Kivity <address@hidden> wrote:
> On 12/06/2011 02:35 PM, Peter Maydell wrote:
>> On 6 December 2011 12:28, Avi Kivity <address@hidden> 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

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.

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.

>> 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.

(Does migration copy across rom contents and sizes?)

-- PMM

reply via email to

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