[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4702D867.2060100@goop.org>
Date: Tue, 02 Oct 2007 16:46:47 -0700
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: Rusty Russell <rusty@...tcorp.com.au>
CC: lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>, Vivek Goyal <vgoyal@...ibm.com>,
lguest <lguest@...abs.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH 0/5] Boot protocol changes
Rusty Russell wrote:
> Hi all,
>
> Jeremy had some boot changes for bzImages, but buried in there was an
> update to the boot protocol to support Xen and lguest (and kvm-lite).
> I've copied those fairly simple patches, and if HPA is happy I'd like to
> push them for 2.6.24 (after correcting for the Great Arch Merge of
> course).
Ah, good. I was thinking about reviving this work. The main problem is
that sticking an ELF header at the 1 meg mark (the address of the
bzImage "payload") breaks 32-bit bootloaders which think they can just
jump to 32-bit code there. I started a conversation with Eric at KS
about it, but we didn't reach any conclusions.
This series looks like a good start for Xen, but we still need to work
out where to stash the metadata which normally lives in ELF notes.
Using ELF is convenient for Xen because it lets a large chunk of domain
builder code be reused; on the other hand, loading a plain bzImage is
pretty simple, so maybe it isn't such a big deal.
HPA, Eric: if we don't go the "embed ELF" path, where's a good
backwards-compatible place to stash the note data? If we do go with
"embed ELF", how should we go about doing it? Arrange to put the ELF
headers before the 1M mark?
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