Re: [Qemu-devel] [PATCH] Add minimal Vexpress Cortex A15 support

[Avi Kivity <avi@redhat.com>]

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