From: ebiederm@xmission.com (Eric W. Biederman)
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: James.Bottomley@HansenPartnership.com,
virtualization@lists.osdl.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: The virtuailization patches break Voyager.
Date: Sat, 28 Apr 2007 01:25:15 -0600 [thread overview]
Message-ID: <m18xcdgdus.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <4632F0E5.1060508@goop.org> (Jeremy Fitzhardinge's message of "Fri, 27 Apr 2007 23:59:49 -0700")
Jeremy Fitzhardinge <jeremy@goop.org> writes:
> Eric W. Biederman wrote:
>> Guys currently I am horrified by the ease at which I can find
>> bugs in the pending paravirtualization patches. I have barely
>> even looked at arch/i386 in the -mm tree and it feels like
>> I am tripping over significant bugs left and right.
>>
>
> Well, I appreciate any and all review comments you have to make.
>
>> Because no one has heeded my advice and put in a proper platform
>> layer on arch/i386 and we are instead doing a half baked job
>> with paravirt_ops it is still trivially easy to miss the
>> fact that subarchitectures do something different, and thus
>> it is easy to miss when you break a sub architecture on
>> arch/i386.
>>
>
> Yes. Though in many ways paravirt_ops is approaching that platform
> layer. In the next round of work, it might be worth renaming it and
> actually using it to subsume the subarch mechanism into something that
> can deal with any architecture at runtime. While this hasn't been an
> explicit goal of the current round of work, I've tried to point things
> in that direction where I can (smp_ops and reboot_ops being specific
> examples of that).
Good. We should do that or at the very least cleanup the
subarchitecture support on arch/i386.
> But you're right; we've been fairly cavalier about Voyager in
> particular, with the hope that James' machine will die before he notices
> we've broken the build. (Or perhaps it has, and he just keeps building
> voyager kernels to torment us.)
Next time I'm in a really tormenting mood I will fire up my
my ibm ps2 with it's 16Mhz 386 and 6MB and verify that all is working
well there.
I really don't think it is ok to be cavalier about anything
that we actually support. Usually if we can handle the general
case it makes for better more maintainable code.
So far the paravirt class of machines seems every bit as much a subarch
as voyager and every bit as interesting.
>> Not that the paravirtuailzation patches are even safe on the
>> primary arch/i386.
>>
>
> Are you referring to the PSE pagetable setup problem we've been
> discussing, or do you have something else in mind?
That is what I was thinking of in particular. But I don't currently
have much faith in the code review process that has been happening
for paravirt patches.
>> Rusty do you think you can address this?
>
> Well, it will probably need to be done after the following patches which
> get rid of the PDA altogether. But the boot-time setup is now pretty
> simple, so it should just be a matter of putting a couple of init_gdts
> in the right places. (It is non-static now too.)
Well at least in 2.6.21-rc7-mm2 init_gdt was still static, and
still in smpboot.c
Eric
next prev parent reply other threads:[~2007-04-28 7:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-28 6:40 The virtuailization patches break Voyager Eric W. Biederman
2007-04-28 6:59 ` Jeremy Fitzhardinge
2007-04-28 7:25 ` Eric W. Biederman [this message]
2007-04-28 7:52 ` Jeremy Fitzhardinge
2007-04-28 8:32 ` Eric W. Biederman
2007-04-28 8:52 ` Jeremy Fitzhardinge
2007-04-28 9:34 ` Andi Kleen
2007-04-28 16:05 ` James Bottomley
2007-04-28 17:15 ` Andi Kleen
2007-04-28 8:42 ` Andi Kleen
2007-04-28 9:13 ` Thomas Gleixner
2007-04-28 9:15 ` Jeremy Fitzhardinge
2007-04-28 9:39 ` Andi Kleen
2007-04-28 9:48 ` Thomas Gleixner
2007-04-28 9:15 ` Eric W. Biederman
2007-04-28 9:37 ` Andi Kleen
2007-04-28 15:24 ` Eric W. Biederman
2007-04-28 16:08 ` James Bottomley
2007-04-28 15:54 ` James Bottomley
2007-04-28 17:15 ` Andi Kleen
2007-04-28 16:40 ` H. Peter Anvin
2007-04-28 17:00 ` Eric W. Biederman
2007-04-28 17:07 ` H. Peter Anvin
2007-04-28 15:47 ` James Bottomley
2007-04-28 16:02 ` Eric W. Biederman
2007-04-28 16:18 ` Jeremy Fitzhardinge
2007-04-28 16:20 ` James Bottomley
2007-04-28 17:23 ` Andi Kleen
2007-04-28 17:22 ` Andi Kleen
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=m18xcdgdus.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=jeremy@goop.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).