RE: [Xen-devel] more segment/selector handling woes

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----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