WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

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

<Prev in Thread] Current Thread [Next in Thread>