mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Rusty Russell <rusty@rustcorp.com.au>, Andi Kleen <ak@suse.de>,
	Chris Wright <chrisw@sous-sol.org>,
	Zachary Amsden <zach@vmware.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 3/3] boot bzImages under paravirt
Date: Fri, 04 May 2007 11:30:02 -0600	[thread overview]
Message-ID: <m16478qyxx.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <463B683C.5090308@zytor.com> (H. Peter Anvin's message of "Fri, 04 May 2007 10:07:08 -0700")

"H. Peter Anvin" <hpa@zytor.com> writes:

> Eric W. Biederman wrote:
>> 
>> We have real mystery historical cases in Gujin and ELILO.  So it
>> probably makes sense at this point to force a gdt reload if we can and
>> otherwise require all of the segments %ds, %es, %fs, %gs to be loaded
>> with a valid segment, that we can reach everything we need to touch
>> from.
>> 
>
> I think we should avoid using %fs and %gs (no use for them, anyway); but
> I think it's a decent expectation to have %cs, %ds, %es, and %ss set up.

Yes we have no need for %fs and %gs.  Lumping them in with the rest is
just extra helpfulness.

Basically be conservative in what you send (all segments).
Be liberal in what you accept (%cs,%ds,%es,%ss) and less if
we can get away with it.

> Gujin seems to have a near-zero user community, so if they have to rev
> their code it wouldn't be a big deal (the author keeps trying to push
> some crack-smoking "Gujin native" patches into the kernel, too), 
> breaking ELILO would hurt anyone using Intel Macs.

I'm thinking we just make the code start.
startup_32:
	movl	%cs, %eax
        testl   $3, %eax
        jnz     1f

	lgdt boot_gdt_descr - __PAGE_OFFSET
	movl $(__BOOT_DS),%eax
	movl %eax,%ds
	movl %eax,%es
	movl %eax,%fs
	movl %eax,%gs
        movl %eax,%ss
1:

But that won't work if we want to support relocatability.
Because we can't load a gdt if we don't know where we are.

To find out where we are we need %ss and %ds, at which point
we might as well assume we have %es to.

I think that will work in the elilo case but we can't reload them.
As silly elilo loaded a new gdt but not it's segments...

So be it then.  The next rev of the boot protocol gets to be partially
incompatible, and we just assume that %cs, %ds, %es, %ss meet our
basic requirements.  I'm pretty certain from what I saw only Gujin
is going to suffer  :(

Yep it is long past time that we document what needs to happen for
the 32bit entry point of the linux kernel.

Eric

  reply	other threads:[~2007-05-04 17:31 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
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 [this message]
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=m16478qyxx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome