| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [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
|
|
|
| |
|
Home