From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LhRUG-0006ay-RC for qemu-devel@nongnu.org; Wed, 11 Mar 2009 12:40:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LhRUG-0006a2-8c for qemu-devel@nongnu.org; Wed, 11 Mar 2009 12:40:56 -0400 Received: from [199.232.76.173] (port=33411 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LhRUG-0006Zd-28 for qemu-devel@nongnu.org; Wed, 11 Mar 2009 12:40:56 -0400 Received: from mail2.shareable.org ([80.68.89.115]:53508) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LhRUF-0006IC-Dj for qemu-devel@nongnu.org; Wed, 11 Mar 2009 12:40:55 -0400 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1LhRUD-00057a-V7 for qemu-devel@nongnu.org; Wed, 11 Mar 2009 16:40:53 +0000 Date: Wed, 11 Mar 2009 16:40:53 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [RESEND][PATCH] x86: Enhanced dump of segment registers Message-ID: <20090311164053.GC18390@shareable.org> References: <49B7C31F.5030201@siemens.com> <20090311161010.GB18390@shareable.org> <49B7E760.2090100@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49B7E760.2090100@siemens.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Jan Kiszka wrote: > Jamie Lokier wrote: > > Jan Kiszka wrote: > >> FS =0000 00000000 00000000 00000000 > > > >> LDT=0000 00000000 00000000 00008200 DPL=0 LDT > > > > Both are =0000, but different descriptors - is that right? > > Good question. My patch only parses to descriptor cache content without > evaluating the selector. I guess that 0x00008200 is a leftover from a > previous, valid LDT descriptor. > > > > > Also I'm thinking the null descriptor doesn't need to show offset and > > size: > > > > FS =0000 > > > > is enough? > > Yes, makes sense. IOW: stop parsing if selector == 0. Will post an update. Hmm. Does a real x86 look at the selector value ever (except when loading it), or does it base all decisions on the descriptor cache? It's an accuracy of emulation thing, as you can legitimately put the CPU into states where the descriptor cache and selector values are inconsistent, and it does have a well-defined behaviour. If a real x86 always uses the descriptor cache, presumably there shouldn't be a leftover value in it when LDT is loaded with 0, and perhaps choosing to show a null descriptor should depend on the descriptor cache entry rather than the selector value. In real mode (and its siblings, unreal mode, big real mode etc.) segment register == 0 usually still has a non-null descriptor. -- Jamie