Message-ID: <463989BD.6040603@goop.org>
Date:	Thu, 03 May 2007 00:05:33 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	vgoyal@...ibm.com, "H. Peter Anvin" <hpa@...or.com>,
	Gerd Hoffmann <kraxel@...hat.com>,
	Jeff Garzik <jeff@...zik.org>, patches@...-64.org,
	linux-kernel@...r.kernel.org,
	virtualization <virtualization@...ts.linux-foundation.org>
Subject: Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for
 relocatable bzImage

Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@...ibm.com> writes:
>
>   
>> On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
>>     
>>> Jeremy Fitzhardinge wrote:
>>>       
>>>> So the bzImage structure is currently:
>>>>
>>>>    1. old-style boot sector
>>>>    2. old-style boot info, followed by 0xaa55 at the end of the sector
>>>>    3. the HdrS boot param block
>>>>    4. setup.S boot code
>>>>    5. the self-decompressing kernel
>>>>
>>>> If we make 5 actually an ELF file, containing properly formed Ehdr,
>>>> Phdrs (for all the mappings required), and the actual kernel
>>>> decompressor, relocator and compressed kernel data, then it would be
>>>> easy for the Xen domain builder to find that and use it as a basis for
>>>> loading.  I think it would just require the bzImage boot param block to
>>>> contain an offset of the start of the ELF file.  The contents of the ELF
>>>> file would be in a form where the normal boot code could just jump over
>>>> the ELF headers, directly into the segment data itself.
>>>>
>>>> ie:
>>>>
>>>>    1. old-style boot sector
>>>>    2. old-style boot info, followed by 0xaa55 at the end of the sector
>>>>    3. the HdrS boot param block
>>>>    4. setup.S boot code (jumps directly into 5.3)
>>>>    5. 32-bit self-decompressing kernel:
>>>>          1. Ehdr
>>>>          2. Phdrs for all necessary mappings
>>>>          3. decompressor/relocator .text
>>>>          4. compressed kernel data
>>>>
>>>> Does that sound reasonable?
>>>>
>>>>         
>>> I don't know if that would break any programs that are currently
>>> bypassing the setup.
>>>       
>
> I think everything will break, unless we make 5.1 and 5.2 
> into 4.2 and 4.3.  In the above design.
>
>   
>> I think kexec bzImage loader will break. It bypasses the setup code and
>> directly jumps to the code present after setup sectors(decompressor).
>>     
>
> Quite likely.    The boot sector except for a handful of bytes actually
> goes unused so we can put extra header information there, I actually
> have patches for placing an ELF header there.

OK, whatever you think will work.  But I do think it should be a proper
ELF file with a correct magic number, so that you can just point an ELF
file parser at it and have it work (which means, of course, that all the
file offsets are offsets from the start of the Ehdr, rather than from
the start of the bzImage).

You haven't specifically commented on using the Phdrs as a way of
specifying the mappings required for decompression and early kernel
execution.  It seems pretty natural to me, but I guess that raises the
general question of what execution environment the kernel can expect to
find itself in, and which modes of booting will actually enable paging
and establish any kinds of mapping at all.

In the Xen case, its obviously the domain builder who creates the
mappings, and we can easily implement p != v mappings.  But when booting
native, presumably paging is off at this stage, and only identity maps
can be implemented.  I guess the rough rule is that if paging is enabled
on entry, the kernel should expect all the bzImage mappings to be in
place, but if paging is off, well, the question is moot.

    J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists