| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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.
>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).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home