From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
"H. Peter Anvin" <hpa@zytor.com>, Andi Kleen <ak@suse.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] i386: always clear bss
Date: Fri, 04 May 2007 07:57:52 -0700 [thread overview]
Message-ID: <463B49F0.401@goop.org> (raw)
In-Reply-To: <m1r6pwu806.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
> Jeremy Fitzhardinge <jeremy@goop.org> writes:
>
>
>> When the paravirt dispatcher gets run immediately on entry to
>> startup_32, the bss isn't cleared. This happens to work if the
>> hypervisor's domain builder loaded the complete kernel image and
>> cleared the bss for us, but this may not always be true (for example,
>> if we're running out of a decompressed bzImage).
>>
>> Change head.S so that it unconditionally clears the bss before doing
>> the paravirt dispatch or continuing on to normal native boot.
>>
>> There are a couple of points to note:
>> - We can't, in general, load the segment registers before paravirt
>> dispatch, because we could be running with a non-standard gdt and
>> segment selectors. In practice though, all code which ends up
>> jumping into startup_32 will have already set the segment registers
>> up to sane values, so we don't need to do it again.
>> - Paging may or may not be enabled, and if enabled we may or may not
>> be mapped to the proper kernel virtual address. To deal with this,
>> we compare the kernel's linked address with where we're actually
>> running, and use that to offset the bss pointer.
>>
BTW, I should have marked this as an RFC comment, rather than an actual
submission. We don't need it for .22.
> NAK.
>
> Skipping the segment register load is likely fine.
> Supporting V!=P at startup_32 is not.
>
Why?
> Assuming that we have a stack at startup_32 is not.
>
> If you want to figure out where the kernel is loaded you can do
> (from arch/i386/boot/head.S)
>
Yes, that's more or less the same code, aside from using 0x40(%esi) as a
stack. Would that be OK here?
J
next prev parent reply other threads:[~2007-05-04 14:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-04 8:21 [PATCH] i386: always clear bss Jeremy Fitzhardinge
2007-05-04 11:46 ` Eric W. Biederman
2007-05-04 14:57 ` Jeremy Fitzhardinge [this message]
2007-05-04 15:22 ` Eric W. Biederman
2007-05-04 15:26 ` Jeremy Fitzhardinge
2007-05-04 15:45 ` Eric W. Biederman
2007-05-04 15:50 ` H. Peter Anvin
2007-05-04 17:05 ` Eric W. Biederman
2007-05-04 17:08 ` H. Peter Anvin
2007-05-04 17:15 ` Eric W. Biederman
2007-05-04 17:26 ` H. Peter Anvin
2007-05-04 19:00 ` Eric W. Biederman
2007-05-04 19:03 ` H. Peter Anvin
2007-05-04 23:17 ` H. Peter Anvin
2007-05-05 1:45 ` Eric W. Biederman
2007-05-05 1:49 ` H. Peter Anvin
2007-05-05 2:11 ` Eric W. Biederman
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=463B49F0.401@goop.org \
--to=jeremy@goop.org \
--cc=ak@suse.de \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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.