[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [RESEND][PATCH] x86: Enhanced dump of segment registers

From: Jan Kiszka
Subject: [Qemu-devel] Re: [RESEND][PATCH] x86: Enhanced dump of segment registers
Date: Wed, 11 Mar 2009 20:24:59 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

Jamie Lokier wrote:
> 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.

Yeah, there is some truth in this. While you can't load NULL into the
task register e.g., it may still work based on its boot-up cache content.

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

Let's don't try to be too clever here (even 0 in all cache fields can
have a meaning in 64-bit mode) and simply keep the output as is.

However, your suggestion led to a nice code cleanup as I folded all
descriptor dumping into a single helper. :)


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]