All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Mikael Petterson <mikpe@it.uu.se>
Subject: Re: [GIT PULL] x86 setup: correct booting on 486 (revised)
Date: Mon, 05 Nov 2007 13:06:58 -0800	[thread overview]
Message-ID: <472F85F2.6040501@zytor.com> (raw)
In-Reply-To: <472F826E.3050008@goop.org>

Jeremy Fitzhardinge wrote:
> H. Peter Anvin wrote:
>> Nailing down the interface as hard as possible is a good idea, to
>> avoid tying your hands for the future. 
> 
> Erm, I guess I see what you mean, but it comes to the effect of tying
> your hands now in a specific way, rather than having them tied in an
> unknown way later on...

Sort of.  The problem is you can frequently not

> But I hadn't noticed the 32-bit boot protocol spec go in.  Unfortunately
> it isn't useful for booting a pv Xen guest; I just mailed my comments. 
> I hope we can iterate this to something more generally useful before
> getting too wedded to the current protocol.

I'm not so sure about that.  Xen PV is rather fundamentally a different 
beast, hence the platform field recently added to the protocol.

>    2. Also, Xen reserves the last chunk of the GDT for its own
>       descriptors, and by default boots the guest with the segment
>       registers preloaded with selectors pointing to flat 4G descriptors
>       in this range.  These segments are not a full 4G, since it uses
>       segment limits to protect the hypervisor from guests.  The limits
>       are as large as they can possibly be.  I like to see the boot
>       protocol require that all segments registers are preloaded with
>       large flat 32-bit descriptors, but not require a specific selector
>       value.  I'd happy to require the GDT to be active, so the segment
>       registers can be reloaded with their current values, until the
>       kernel establishes its own GDT.


This is addressed by the "don't reload segments" bit in LOADFLAGS.

	-hpa

  reply	other threads:[~2007-11-05 21:10 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-05  2:16 [GIT PULL] x86 setup: correct booting on 486 (revised) H. Peter Anvin
2007-11-05  3:58 ` H. Peter Anvin
2007-11-05 17:15   ` Linus Torvalds
2007-11-05 17:56     ` H. Peter Anvin
2007-11-05 18:12       ` Linus Torvalds
2007-11-05 18:32         ` H. Peter Anvin
2007-11-05 18:36           ` Linus Torvalds
2007-11-05 20:21             ` Eric W. Biederman
2007-11-05 20:31               ` H. Peter Anvin
2007-11-05 20:51                 ` Jeremy Fitzhardinge
2007-11-05 21:06                   ` H. Peter Anvin [this message]
2007-11-06  0:59                     ` Jeremy Fitzhardinge
2007-11-06  1:11                       ` H. Peter Anvin
2007-11-06  1:18                         ` Jeremy Fitzhardinge
2007-11-06  1:31                           ` H. Peter Anvin
2007-11-06 16:17                             ` Jeremy Fitzhardinge
2007-11-06 16:27                               ` H. Peter Anvin
2007-11-06 16:55                                 ` Jeremy Fitzhardinge
2007-11-06 17:00                                   ` H. Peter Anvin
2007-11-06 17:09                                     ` Eric W. Biederman
2007-11-06 17:57                                       ` H. Peter Anvin
2007-11-06 18:27                                         ` Eric W. Biederman
2007-11-06 18:41                                           ` H. Peter Anvin
2007-11-06 17:04                                 ` Eric W. Biederman
2007-11-05 21:14                 ` Eric W. Biederman
2007-11-05 21:28                   ` H. Peter Anvin
2007-11-05 21:58                     ` 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=472F85F2.6040501@zytor.com \
    --to=hpa@zytor.com \
    --cc=ebiederm@xmission.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikpe@it.uu.se \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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.