From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: RE: more segment/selector handling woes Date: Wed, 22 Nov 2006 14:08:26 +0100 Message-ID: <456459DA.76E4.0078.0@novell.com> References: <45644667.76E4.0078.0@novell.com> <907625E08839C4409CE5768403633E0B018E174D@sefsexmb1.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <907625E08839C4409CE5768403633E0B018E174D@sefsexmb1.amd.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mats Petersson Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >> 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