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] more segment/selector handling woes

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] more segment/selector handling woes
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Wed, 22 Nov 2006 14:36:56 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 22 Nov 2006 05:40:37 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <456459DA.76E4.0078.0@xxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AccONxzFC38D16YdRSKPlgvIkiNYxQAA5/fg
Thread-topic: [Xen-devel] more segment/selector handling woes
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Jan Beulich
> Sent: 22 November 2006 13:08
> To: Petersson, Mats
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] more segment/selector handling woes
> 
> >> Note the wording 'as if' - this doesn't tell me whether the 
> >> internal base
> >> address field (which gets stored to the vmcb) can indeed be 
> >> relied upon.
> >> But obviously the code would be simpler if that was the case 
> >> in reality
> >> (and then perhaps the documentation could be updated accordingly).
> >
> >I believe it would contain whatever is in the [GL]DT... It's 
> ignored by
> >the processor (treated as zero). So, you'd have to check if 
> it's GS/FS
> >or not, and then use either 0 or [fg]s.base accordingly. 
> 
> Can you verify this with you hardware guys? It would mean that I'd
> also have to change the implementation of get_segment_base()
> that I introduced with a patch yesterday.

I'll check with someone. I'll hopefully have a reply early afternoon,
but no guarantees... 


> 
> >Note that one bit in EFER also allows limits for 64-bit 
> segments, but I
> >think it's only ever used by VMWare, so it's probably OK to 
> ignore the
> >limits completely (in 64-bit mode at least). 
> 
> Is this being detailed anywhere? Namely, whether there's a CPUID
> feature flag for this (or is it always available), and how one would
> obtain 64-bit wide limits? I merely can see the flag being defined in
> the NPT BIOS And Kernel Developer's Guide (the public
> Programmer's Manual doesn't even know this).

There's no 64-bit segment limit, it's a 32-bit value (actually 20 bit,
with an optional 12 bit shift-and-fill-with-ones) just as in 32-bit
mode. 

There's no other public documentation at the moment. I've seen a
presentation set that describes it in more detail, I'll see if I can dig
that out [and see if it's marked "NDA" or not!]. 

It's safe to ignore it for now, I should think. 

--
Mats
> 
> Jan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel