Re: [Qemu-devel] [PATCH] QEMU: ARM: boot: Load kernel at an Image friendly address

[Peter Crosthwaite]

On Fri, Apr 18, 2014 at 5:26 AM, Peter Maydell <address@hidden> wrote:
> On 17 April 2014 17:58, Rob Herring <address@hidden> wrote:
>> On Thu, Apr 17, 2014 at 5:02 AM, Peter Maydell <address@hidden> wrote:
>>> On 2 April 2014 13:47, Peter Maydell <address@hidden> wrote:
>>>> On 2 April 2014 13:11, Peter Crosthwaite <address@hidden> wrote:
>>>>> Like others, I have been carrying this change locally. Good to see it up!
>>>>
>>>> Why are you all booting raw Images anyway (just out of curiosity)?
>>>
>>> Given the recent feedback from the kernel mailing list (viz "don't boot
>>> Image unless you really know what you're doing, the correct load
>>> image may change randomly depending what other board support
>>> is in a multikernel image, etc") maybe we should just remove the
>>> Image booting support instead? Clearly nobody who hasn't locally
>>> patched QEMU is using it at the moment...
>>
>> Including AArch64, too? :) It happens to be correct ATM, but really we
>> should be looking the Image header to determine the offset. I heard
>> Mark Rutland has some patches to do TEXT_OFFSET randomization in fact.
>
> AArch64 is different -- the Image format is sanely specified and
> includes enough information to get it right. (The fact that we don't
> currently do so is a clear QEMU bug.)
>
>> The choice of 0x10000 is not really a good one either as this forces
>> the decompressor to move itself out of the way first. I guess it is a
>> good choice if your goal is to test the worst possible code path for
>> the decompressor.
>
> The major awkwardness with AArch32 zImage is that it doesn't
> give you enough information to know how big the zImage will
> be uncompressed, so it's not possible for the bootloader to
> sanity check that all the various bits and pieces aren't going
> to overlap (and the kernel doesn't check either IIRC, so if things go
> wrong they go wrong in various obscure ways).
>
> We could certainly rearrange where QEMU puts things; the current
> setup results from a mixture of:
>  * legacy "this is how we've always done it" (and the fact that if we
>    get things wrong and the uncompressed kernel overlaps with the
>    DTB or initrd then the failure is unhelpfully cryptic has generally
>    been a pressure towards "don't tweak things too much")
>  * handling both Image and zImage (and now AArch64 Image)
>    in broadly similar codepaths
>  * wanting to handle both boards with what by modern standards are
>     tiny amounts of memory and also boards with gigabytes of RAM,
>     even though optimal choices for location are going to differ
>
> I don't insist that we drop AArch32 Image support (or necessarily
> even think we should gratuitously do so), but if it
> makes it simpler to refactor the code to better handle the
> other options then I don't particularly object to that happening.
> I do think that it seems like an AArch32 Image loader that would
> be useful to end-users ought to provide them with some way to
> specify the load address or offset.
>

Regarding implementation of new bootloader specific user properties -
the issue was discussed in my attempt to QOMify the ARM bootloader:

http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00962.html

Now that the dust has settled on QOM (I believe that QOM instability
was a dis-encouraging factor at that time). Perhaps we should revist
that QOMification idea and punch all these magic numbers through as
(over-ridable) props? -global and friends does the rest without ARM
specific intrusion on machine and boot opts (vl.c etc).

Regards,
Peter

> thanks
> -- PMM
>