From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
"H. Peter Anvin" <hpa@zytor.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
Vivek Goyal <vgoyal@in.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
v12n <virtualization@lists.linux-foundation.org>
Subject: [PATCH 0/9] x86 boot protocol updates
Date: Wed, 20 Jun 2007 16:17:26 -0700 [thread overview]
Message-ID: <20070620231726.834538992@goop.org> (raw)
[ This patch depends on the cross-architecture ELF cleanup patch. ]
This series updates the boot protocol to 2.07 and uses it to implement
paravirtual booting. This allows the bootloader to tell the kernel
what kind of hardware/pseudo-hardware environment it's coming up under,
and the kernel can use the appropriate boot sequence code.
Specifically:
- Update the boot protocol to 2.07, which adds fields to specify the
hardware subarchitecture and some subarchitecture-specific data.
It also specifies a flag to tell the boot code to avoid reloading
segment registers and playing with interrupt state, since it may not
have a visible gdt and/or may not be running in ring 0.
(Note: the segment reload and interrupt flags are conflated into one
flag, but they are not really related. We could have two flags, but
the "cli" is probably completely redundant anyway, since the bootloader
would have to be completely mad to start the kernel with interrupts
enabled.)
- Change the format of bzImage to contain an ELF file. The initial part of
the bzImage is still the boot_params header followed by the 16-bit
setup code needed for booting from BIOS. But rather than having
the self-decompressing kernel follow as a naked blob of code+data,
its actually wrapped in a page-aligned ELF file. This allows the
bootloader to extract it and parse it, and use that to know what
memory the booting kernel will need initially. Xen and lguest need
this because they start the kernel with paging enabled, and so need
to know what initial mappings to create.
- Modify the kernel boot sequence to:
1. avoid reloading the segment state (gdt and segment registers) if the
bootloader asks it to
2. jump to a subarchitecture-specific entrypoint in kernel/head.S.
- Add Xen-specific starup code, which mainly remaps the kernel from
its P=V identity mapping to the normal PAGE_OFFSET mapping.
One open issue is that I haven't made the normal head.S initial
pagetable construction code generally reusable. The default
boot-on-normal x86 hardware still uses it of course, but other
subarchitectures like Voyager and lguest could probably use it as-is,
while still needing to do other specialized things.
The obvious fix is to make it a callable function, but we don't
generally assume there's a stack available at this early stage.
It looks like it would be easy to set one up though.
As a pre-requisite for all the above, I've also cleaned up the bzImage
build process process. I've eliminated the need for the tools/build
program, and instead use the linker to do more heavy lifting. I've also
removed some somewhat obscure uses of ld and objcopy wrap binary files
in ELF .o wrappers, and replaced with with .S files containing .incbin.
The downside is that its making a bit more complex use of linker scripts,
which always opens scope for finding more binutils bugs. Only one way
to find out...
Tested to check the generated kernels boot under qemu's internal bootload
and grub, as well as booting under Xen (with an appropriate update to
the Xen domain builder).
TODO:
- poke Rusty into implementing the lguest bits
- look at Kbuild use in arch/{i386,x86_64}/boot/
J
--
next reply other threads:[~2007-06-20 23:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-20 23:17 Jeremy Fitzhardinge [this message]
2007-06-20 23:17 ` [PATCH 1/9] update boot spec to 2.07 Jeremy Fitzhardinge
2007-06-20 23:17 ` [PATCH 2/9] define ELF notes for adding to a boot image Jeremy Fitzhardinge
2007-06-20 23:17 ` [PATCH 3/9] i386: clean up bzImage generation Jeremy Fitzhardinge
2007-06-20 23:17 ` [PATCH 4/9] i386: make the bzImage payload an ELF file Jeremy Fitzhardinge
2007-06-20 23:17 ` [PATCH 5/9] add WEAK() for creating weak asm labels Jeremy Fitzhardinge
2007-06-20 23:17 ` [PATCH 6/9] always allocate space for notes Jeremy Fitzhardinge
2007-06-20 23:17 ` [PATCH 7/9] i386: paravirt boot sequence Jeremy Fitzhardinge
2007-06-20 23:17 ` [PATCH 8/9] ask the hypervisor how much space it needs reserved Jeremy Fitzhardinge
2007-06-20 23:17 ` [PATCH 9/9] xen: use boot protocol to boot xen kernel Jeremy Fitzhardinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070620231726.834538992@goop.org \
--to=jeremy@goop.org \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@in.ibm.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).