|
|
|
|
|
|
|
|
|
|
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 11:45
> To: Petersson, Mats
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] more segment/selector handling woes
>
> >> Not only on VMX and in generic code, but also on SVM now:
> >> svm_get_io_address() uses the segment base only when the guest
> >> is not in long mode - what if outs has an fs/gs override?
> I'm pretty
> >> sure the base address is needed then, which opens the question -
> >> does the CPU guarantee a valid (zero) base also for the other
> >> segment register, or does this need to be conditionalized?
> >
> >Good question. I think you've found a bug, fs/gs should be taken into
> >consideration in 64-bit mode.
> >
> >The x86-64 architecture "guarantees" that the base is zero
> in long-mode.
> >
> >
> >More precisely, page 110 in the December 2005 AMD64 PRM Vol 2:
> >* In data-segment descriptors referenced by DS, ES and SS segment
> >registers, the base-address field is ignored,. For the purpose of
> >virtual-address calculations, the base address is treates as
> if it has a
> >value of zero.
>
> 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.
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).
--
Mats
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|