From: Rusty Russell <rusty@rustcorp.com.au>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
Chris Wright <chrisw@sous-sol.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Virtualization Mailing List <virtualization@lists.osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Extending boot protocol & bzImage for paravirt_ops
Date: Sat, 26 May 2007 20:18:11 +1000 [thread overview]
Message-ID: <1180174691.650.8.camel@localhost.localdomain> (raw)
In-Reply-To: <m14pm0c0m2.fsf@ebiederm.dsl.xmission.com>
On Fri, 2007-05-25 at 10:46 -0600, Eric W. Biederman wrote:
> Most of that though is just packaging. The meat of the issue
> is how do we upgrade the bootloader data. Do the changes
> below sound like everything we need?
>
> Field name: loadflags
> Type: modify (obligatory)
> Offset/size: 0x211/1
> Protocol: 2.00+
>
> This field is a bitmask.
>
> Bit 0 (read): LOADED_HIGH
> - If 0, the protected-mode code is loaded at 0x10000.
> - If 1, the protected-mode code is loaded at 0x100000.
>
> + Bit 6 (write): KEEP_SEGMENTS
> + Protocol: 2.07+
> + - if 0, reload the segment registers in the 32bit entry point.
> + - if 1, do not reload the segment registers in the 32bit entry point.
> + Assume that %cs %ds %ss %es are all set to flat segments with
> + a base of 0 (or the equivalent for their environment).
You also want to skip the cli: perhaps a separate flag for this is
appropriate though.
Rest looks fine from an lguest POV. We don't need the platform data
field either, since we use the first hypercall to get that).
Cheers,
Rusty.
next prev parent reply other threads:[~2007-05-26 10:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-25 15:06 Extending boot protocol & bzImage for paravirt_ops Jeremy Fitzhardinge
2007-05-25 16:46 ` Eric W. Biederman
2007-05-26 10:18 ` Rusty Russell [this message]
2007-05-26 20:42 ` H. Peter Anvin
2007-05-26 23:47 ` Jeremy Fitzhardinge
2007-05-27 0:10 ` Rusty Russell
2007-05-27 0:15 ` H. Peter Anvin
2007-05-26 23:47 ` Jeremy Fitzhardinge
2007-05-27 0:14 ` H. Peter Anvin
2007-05-27 0:19 ` Jeremy Fitzhardinge
2007-05-30 23:16 ` Jeremy Fitzhardinge
2007-05-31 8:08 ` Vivek Goyal
2007-06-01 20:55 ` Jeremy Fitzhardinge
2007-06-01 21:40 ` H. Peter Anvin
2007-06-01 21:47 ` Jeremy Fitzhardinge
2007-06-01 21:57 ` H. Peter Anvin
2007-06-02 0:37 ` Jeremy Fitzhardinge
2007-06-02 0:42 ` H. Peter Anvin
2007-06-02 0:58 ` Jeremy Fitzhardinge
2007-06-02 1:02 ` H. Peter Anvin
2007-06-02 1:08 ` Jeremy Fitzhardinge
2007-06-02 1:17 ` 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=1180174691.650.8.camel@localhost.localdomain \
--to=rusty@rustcorp.com.au \
--cc=chrisw@sous-sol.org \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).