[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <463B4E12.50703@goop.org>
Date: Fri, 04 May 2007 08:15:30 -0700
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@...e.de>,
Chris Wright <chrisw@...s-sol.org>,
Zachary Amsden <zach@...are.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>,
lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 3/3] boot bzImages under paravirt
Eric W. Biederman wrote:
> Ok. Although we can hoist the bss zeroing, if everything needs it.
>
It will if we're booting out of bzImage; the bss won't be clear in that
case.
> Hmm. I'm wondering about the segment reload and how much of a problem
> that is. My memory says that segment reloads are not actually a
> privileged operation, so we may be able to support this even in
> paravirt mode. How hard would that be to support? The segment
> we reload is a fixed part of our boot protocol.
>
The problem is not the reloads themselves, but what you're reloading
them with. If we come up under Xen, then it will provide a default GDT
and pre-load the segments with flat 4G(-ish) selectors - but the
selectors won't be the normal Linux ones.
So if we reload using a constant selector, then that will break under
Xen. But if we do a:
mov %cs, %eax
mov %eax, %ds
// etc
sequence then it should be fine. This will work even for loading %ss,
since the %cs CPL will equal the RPL needed for %ss.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists