From: ebiederm@xmission.com (Eric W. Biederman)
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andi Kleen <ak@suse.de>, Chris Wright <chrisw@sous-sol.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Zachary Amsden <zach@vmware.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"H. Peter Anvin" <hpa@zytor.com>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 3/3] boot bzImages under paravirt
Date: Fri, 04 May 2007 08:38:53 -0600 [thread overview]
Message-ID: <m1ps5gslfm.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <1178284052.23670.75.camel@localhost.localdomain> (Rusty Russell's message of "Fri, 04 May 2007 23:07:32 +1000")
Rusty Russell <rusty@rustcorp.com.au> writes:
> (This is kind of a bonus, but it shows how minor the change is to boot
> bzImages)
>
> Skipping over the "cli" and segment loading is enough to allow lguest
> to boot bzImages. There are some "out" insns in the unpacking code,
> but lguest already has to emulate/skip-over them because of random x86
> probes during boot.
>
> We can no longer assume the launcher has set the bss to zero: we now
> need to zero it ourselves.
Ok. Although we can hoist the bss zeroing, if everything needs it.
Are you booting with P=V now? If not I expect you will run
into trouble if you set CONFIG_RELOCATABLE.
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> ---
> Documentation/lguest/lguest.c | 134 +++++++-------------------------------
> arch/i386/boot/compressed/head.S | 6 +
> drivers/lguest/core.c | 8 +-
> drivers/lguest/lguest.c | 2
> 4 files changed, 41 insertions(+), 109 deletions(-)
>
> diff -r 73d71b701360 arch/i386/boot/compressed/head.S
> --- a/arch/i386/boot/compressed/head.S Fri May 04 22:49:34 2007 +1000
> +++ b/arch/i386/boot/compressed/head.S Fri May 04 22:51:49 2007 +1000
> @@ -32,6 +32,11 @@
> .globl startup_32
>
> startup_32:
> +#ifdef CONFIG_PARAVIRT
> + movl %cs,%eax
> + andl $0x3,%eax
> + jnz calc_delta
> +#endif
> cld
> cli
> movl $(__BOOT_DS),%eax
> @@ -48,6 +53,7 @@ startup_32:
> * data at 0x34-0x3f are used as the stack for this calculation.
> * Only 4 bytes are needed.
> */
> +calc_delta:
> leal 0x40(%esi), %esp
> call 1f
> 1: popl %ebp
In essence this is ok. I would like to do the research to see if we
can perhaps just remove the segment reload. Short of that we should
at least be able to remove the unnecessary preprocessor test for
CONFIG_PARAVIRT.
Hmm. I'm wondering about the segment reload and how much of a problem
that is. My memory says that segment reloads are not actually a
privileged operation, so we may be able to support this even in
paravirt mode. How hard would that be to support? The segment
we reload is a fixed part of our boot protocol.
Anyway something to research.
> +#warning document this with reference to Documentation/i386/boot.txt
> + u8 hdr[0x300];
> + int r;
> + void *p = (void *)0x100000;
> +
> + lseek(fd, 0, SEEK_SET);
> + read(fd, hdr, sizeof(hdr));
> +
> + lseek(fd, (unsigned long)(hdr[0x1F1]+1) * 512, SEEK_SET);
I guess this works. You don't handle the old case of set_sectors == 0
but I guess you don't support any kernels where that is the case.
> +
> + while ((r = read(fd, p, 65535)) > 0)
> + p += r;
> +
> + return *(unsigned long *)&hdr[0x214];
> }
>
> /*L:140 Loading the kernel is easy when it's a "vmlinux", but most kernels
Eric
next prev parent reply other threads:[~2007-05-04 14:40 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-04 12:59 [RFC PATCH 1/3] Replace paravirt_probe with "platform type" boot header field Rusty Russell
2007-05-04 13:02 ` [RFC PATCH 2/3] lguest: Boot with virtual == physical to get closer to native Linux Rusty Russell
2007-05-04 13:07 ` [RFC PATCH 3/3] boot bzImages under paravirt Rusty Russell
2007-05-04 14:38 ` Eric W. Biederman [this message]
2007-05-04 14:55 ` Rusty Russell
2007-05-04 15:49 ` H. Peter Anvin
2007-05-04 15:15 ` Jeremy Fitzhardinge
2007-05-04 15:45 ` H. Peter Anvin
2007-05-04 16:13 ` Jeremy Fitzhardinge
2007-05-04 16:43 ` H. Peter Anvin
2007-05-04 16:57 ` Eric W. Biederman
2007-05-04 17:07 ` H. Peter Anvin
2007-05-04 17:30 ` Eric W. Biederman
2007-05-04 18:22 ` Jeremy Fitzhardinge
2007-05-04 18:48 ` Eric W. Biederman
2007-05-04 18:55 ` Jeremy Fitzhardinge
2007-05-04 19:21 ` Eric W. Biederman
2007-05-04 16:46 ` Eric W. Biederman
2007-05-04 17:25 ` Jeremy Fitzhardinge
2007-05-04 17:27 ` H. Peter Anvin
2007-05-04 17:36 ` Eric W. Biederman
2007-05-04 17:44 ` H. Peter Anvin
2007-05-04 18:25 ` Jeremy Fitzhardinge
2007-05-04 14:01 ` [RFC PATCH 1/3] Replace paravirt_probe with "platform type" boot header field Eric W. Biederman
2007-05-04 14:18 ` Rusty Russell
2007-05-04 14:23 ` Eric W. Biederman
2007-05-04 15:52 ` H. Peter Anvin
2007-05-04 16:48 ` Eric W. Biederman
2007-05-04 17:13 ` H. Peter Anvin
2007-05-04 18:30 ` Eric W. Biederman
2007-05-04 18:55 ` H. Peter Anvin
2007-05-04 19:10 ` Eric W. Biederman
2007-05-04 19:14 ` H. Peter Anvin
2007-05-04 19:31 ` Eric W. Biederman
2007-05-04 19:19 ` H. Peter Anvin
2007-05-04 15:10 ` Eric W. Biederman
2007-05-04 15:53 ` H. Peter Anvin
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=m1ps5gslfm.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=chrisw@sous-sol.org \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@linux-foundation.org \
--cc=zach@vmware.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.