|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [Patch] Fix for x86_64 boot failures due to bad segment
To: |
Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> |
Subject: |
Re: [Xen-devel] [Patch] Fix for x86_64 boot failures due to bad segment setup for protected mode. |
From: |
Steven Rostedt <srostedt@xxxxxxxxxx> |
Date: |
Thu, 09 Nov 2006 07:56:50 -0500 |
Cc: |
Wilfred Yu <wilfred.yu@xxxxxxxxx>, Xiaohui Xin <xiaohui.xin@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Susie Li <susie.li@xxxxxxxxx>, "Li, Xin B" <xin.b.li@xxxxxxxxx>, Herbert Xu <herbert.xu@xxxxxxxxxx> |
Delivery-date: |
Thu, 09 Nov 2006 04:57:19 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
In-reply-to: |
<C1789DB2.40E9%Keir.Fraser@xxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<C1789DB2.40E9%Keir.Fraser@xxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Thunderbird 1.5.0.4 (X11/20060614) |
Keir Fraser wrote:
On 9/11/06 3:49 am, "Stephen C. Tweedie" <sct@xxxxxxxxxx> wrote:
The fix is to save the 16-bit segments *always*, on entry to protected
mode when %CR0(PE) is first set; and to clear the saved 16-bit segment
and set the 32-bit variant in oldctx whenever a 32-bit segment
descriptor is set during the transition to 32-bit CS. Then, when we
finally do the VMENTER, we will set up the VMCS from only the 32-bit
segments, clearing the VMCS entries for segments that have not been
assigned valid 32-bit segments yet.
So, after setting CR0.PE but before doing a jump to complete the transition
to protected mode, is the guest now running with zeroed data selectors but
with the old 'shadow segment state'? So it can still use its data segments
until the long jump? Not that I know whether any bootloader would actually
*want* to access data in that critical region....
Keir,
oldctx.*_sel is basically the shadow selector. They are not used in
emulating the code during the single step. So zeroing them out is fine.
The regs structure is what is used in calculating getting data in the
data segments.
The main thing here that Stephen's approach is different to the previous
approach, is that if a segment descriptor *is* changed (ie. %es for
Vista) then we have to update the oldctx explicitly for that selector.
So far the only place we see this is with the "pop %es". And Stephen
put in the proper code to update that descriptor.
The old approach would just update all the selectors if they fit inside
the GDT table, whether or not they were changed or loaded. So when Linux
had a bad (extremely large) GDT limit, we loaded all the selectors into
the shadow selector, even though they were bogus.
-- Steve
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|