From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>, Andi Kleen <ak@suse.de>,
Chris Wright <chrisw@sous-sol.org>,
Jeremy Fitzhardinge <jeremy@goop.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 1/3] Replace paravirt_probe with "platform type" boot header field
Date: Fri, 04 May 2007 13:31:47 -0600 [thread overview]
Message-ID: <m14pmspeqk.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <463B8629.3090309@zytor.com> (H. Peter Anvin's message of "Fri, 04 May 2007 12:14:49 -0700")
"H. Peter Anvin" <hpa@zytor.com> writes:
> Indeed. I think, yes, what has been there up to now has pretty much
> been at least in part experimental, and I fear there will be unavoidable
> breakage as part of sanitizing it. C'est la vie, I guess.
The one significant one I left out I think is the VISWS. I'm not certain
what we do there, but I know it never went through setup.S
Yes. At the same time we have been sufficiently disciplined (baring
paravirt) that the changes should be quite small, and we have a big
enough sample size now that we can pretty clearly see ways in which
the code will vary.
>>>> And 4K seems to be our maximum size for backwards compatibility. Although
>>>> we use it in a fairly sparse way, so we should be ok.
>>> Sort of. It's pretty full.
>>
>> True. For small little extensions we have room. For big things probably
>> not.
>
> For big extensions we'll probably have to go the pointer route already
> done with the command line.
Likely. It is tricky because if we actually have to do a normal BIOS
query to get it things a little sticky, because we can't allocate
memory. Hmm. It looks like we need a way to export the size of
our parameter area to the bootloader. We have setup_sects for 16bit
real mode bootloaders and that should be good enough, but we need
something equivalent for the 32bit entry point.
Requirements analysis here we come.
Eric
next prev parent reply other threads:[~2007-05-04 19:33 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-04 12:59 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
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 [this message]
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=m14pmspeqk.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