mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: 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>,
	"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 11:36:37 -0600	[thread overview]
Message-ID: <m11whwqymy.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <463B6C8A.9080206@goop.org> (Jeremy Fitzhardinge's message of "Fri, 04 May 2007 10:25:30 -0700")

Jeremy Fitzhardinge <jeremy@goop.org> writes:

> Eric W. Biederman wrote:
>> Hmm. If we made that:
>> 	mov	%cs, %eax
>> 	add	$0x10, %eax
>> 	mov	%eax, %ds
>>
>> That is likely even backwards compatible.  If you don't mind having a fixed
>> offset between the code and the data segments.  As I recall code and data
>> are not interchangeable.
>>   
>
> Yes, that's just bogus thinko on my part.
>
>> I'm trying to remember the reason for the reloads.
>>
>> As I recall loadlin intercepts code32_start from head.S and so it
>> can do things just after we have switched to protected mode.  Because
>> historically we didn't load the segments before this jump loadlin had
>> to do it.  The code of loadlin appears to reload all of the segments
>> just like head.S does and then not touch them.
>>
>> My two bootloaders that enter the kernel at the 32bit entry point already
>> load the segments as well.
>>
>> Gujin looks like it loads just %es and %ds.
>>   
>
> We should be able to make do with that until we've got our own gdt.

Right after the segments loads we have:
	leal 0x40(%esi), %esp
	call 1f
1:	popl %ebp
	subl $1b, %ebp

That uses %ss and %ds.  Can we use a segment override on a call
instruction?

>> It is hard to tell with elilo what it sets up, it preserves the
>> descriptors from EFI, but sets up a linux boot protocol gdt.
>>   
>
> ? But the cached descriptors are still the EFI ones?

Yep.  Which means we can reload with our know good linux descriptors
but we can't reload the descriptors we are currently running with. 

>> At the same time we are doing this it would be good to drop our
>> boot protocol version into an ELF note so people booting vmlinux
>> can discover when we have relaxed various restrictions and which
>> fields in the real mode data we support.
>>   
>
> Do you mean the have the kernel expose its max supported version for
> bootloaders to inspect?

Yes.  Exactly like we do for real mode code, and with exactly the same
values.  Just in a little different format.

Eric

  parent reply	other threads:[~2007-05-04 17:37 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
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 [this message]
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=m11whwqymy.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

all inboxes | Powered by JetHome®