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