* [Qemu-devel] [RESEND][PATCH] x86: Enhanced dump of segment registers
@ 2009-03-11 13:56 Jan Kiszka
2009-03-11 16:10 ` Jamie Lokier
2009-03-11 19:40 ` [Qemu-devel] [PATCH v2] " Jan Kiszka
0 siblings, 2 replies; 11+ messages in thread
From: Jan Kiszka @ 2009-03-11 13:56 UTC (permalink / raw)
To: qemu-devel
Parse the descriptor flags that segment registers refer to and show the
result in a more human-friendly format. The output of info registers eg.
then looks like this:
[...]
ES =007b 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0060 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
SS =0068 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
DS =007b 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0000 00000000 00000000 00000000
GS =0033 b7dd66c0 ffffffff b7dff3dd DPL=3 DS [-WA]
LDT=0000 00000000 00000000 00008200 DPL=0 LDT
TR =0080 c06da700 0000206b 00008900 DPL=0 TSS32-avl
[...]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
target-i386/cpu.h | 3 ++
target-i386/helper.c | 62 +++++++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 58 insertions(+), 7 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 90bceab..f38f194 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -82,9 +82,10 @@
#define DESC_AVL_MASK (1 << 20)
#define DESC_P_MASK (1 << 15)
#define DESC_DPL_SHIFT 13
-#define DESC_DPL_MASK (1 << DESC_DPL_SHIFT)
+#define DESC_DPL_MASK (3 << DESC_DPL_SHIFT)
#define DESC_S_MASK (1 << 12)
#define DESC_TYPE_SHIFT 8
+#define DESC_TYPE_MASK (15 << DESC_TYPE_SHIFT)
#define DESC_A_MASK (1 << 8)
#define DESC_CS_MASK (1 << 11) /* 1=code segment 0=data segment */
diff --git a/target-i386/helper.c b/target-i386/helper.c
index 8213703..d6a0e7d 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -570,6 +570,50 @@ static const char *cc_op_str[] = {
"SARQ",
};
+static void
+cpu_x86_dump_desc_flags(CPUState *env, FILE *f,
+ int (*cpu_fprintf)(FILE *f, const char *fmt, ...),
+ uint32_t dflags)
+{
+ if (!(env->hflags & HF_PE_MASK) || !(dflags & DESC_P_MASK))
+ goto done;
+
+ cpu_fprintf(f, " DPL=%d ", (dflags & DESC_DPL_MASK) >> DESC_DPL_SHIFT);
+ if (dflags & DESC_S_MASK) {
+ if (dflags & DESC_CS_MASK) {
+ cpu_fprintf(f, (dflags & DESC_L_MASK) ? "CS64" :
+ ((dflags & DESC_B_MASK) ? "CS32" : "CS16"));
+ cpu_fprintf(f, " [%c%c", (dflags & DESC_C_MASK) ? 'C' : '-',
+ (dflags & DESC_R_MASK) ? 'R' : '-');
+ } else {
+ cpu_fprintf(f, (dflags & DESC_B_MASK) ? "DS " : "DS16");
+ cpu_fprintf(f, " [%c%c", (dflags & DESC_E_MASK) ? 'E' : '-',
+ (dflags & DESC_W_MASK) ? 'W' : '-');
+ }
+ cpu_fprintf(f, "%c]", (dflags & DESC_A_MASK) ? 'A' : '-');
+ } else {
+ static const char *sys_type_name[2][16] = {
+ { /* 32 bit mode */
+ "Reserved", "TSS16-avl", "LDT", "TSS16-busy",
+ "CallGate16", "TaskGate", "IntGate16", "TrapGate16",
+ "Reserved", "TSS32-avl", "Reserved", "TSS32-busy",
+ "CallGate32", "Reserved", "IntGate32", "TrapGate32"
+ },
+ { /* 64 bit mode */
+ "<hiword>", "Reserved", "LDT", "Reserved", "Reserved"
+ "Reserved", "Reserved", "Reserved", "Reserved",
+ "TSS64-avl", "Reserved", "TSS64-busy", "CallGate64",
+ "Reserved", "IntGate64", "TrapGate64"
+ }
+ };
+ cpu_fprintf(f, sys_type_name[(env->hflags & HF_LMA_MASK) ? 1 : 0]
+ [(dflags & DESC_TYPE_MASK)
+ >> DESC_TYPE_SHIFT]);
+ }
+done:
+ cpu_fprintf(f, "\n");
+}
+
void cpu_dump_state(CPUState *env, FILE *f,
int (*cpu_fprintf)(FILE *f, const char *fmt, ...),
int flags)
@@ -652,23 +696,26 @@ void cpu_dump_state(CPUState *env, FILE *f,
if (env->hflags & HF_LMA_MASK) {
for(i = 0; i < 6; i++) {
SegmentCache *sc = &env->segs[i];
- cpu_fprintf(f, "%s =%04x %016" PRIx64 " %08x %08x\n",
+ cpu_fprintf(f, "%s =%04x %016" PRIx64 " %08x %08x",
seg_name[i],
sc->selector,
sc->base,
sc->limit,
sc->flags);
+ cpu_x86_dump_desc_flags(env, f, cpu_fprintf, sc->flags);
}
- cpu_fprintf(f, "LDT=%04x %016" PRIx64 " %08x %08x\n",
+ cpu_fprintf(f, "LDT=%04x %016" PRIx64 " %08x %08x",
env->ldt.selector,
env->ldt.base,
env->ldt.limit,
env->ldt.flags);
- cpu_fprintf(f, "TR =%04x %016" PRIx64 " %08x %08x\n",
+ cpu_x86_dump_desc_flags(env, f, cpu_fprintf, env->ldt.flags);
+ cpu_fprintf(f, "TR =%04x %016" PRIx64 " %08x %08x",
env->tr.selector,
env->tr.base,
env->tr.limit,
env->tr.flags);
+ cpu_x86_dump_desc_flags(env, f, cpu_fprintf, env->tr.flags);
cpu_fprintf(f, "GDT= %016" PRIx64 " %08x\n",
env->gdt.base, env->gdt.limit);
cpu_fprintf(f, "IDT= %016" PRIx64 " %08x\n",
@@ -687,23 +734,26 @@ void cpu_dump_state(CPUState *env, FILE *f,
{
for(i = 0; i < 6; i++) {
SegmentCache *sc = &env->segs[i];
- cpu_fprintf(f, "%s =%04x %08x %08x %08x\n",
+ cpu_fprintf(f, "%s =%04x %08x %08x %08x",
seg_name[i],
sc->selector,
(uint32_t)sc->base,
sc->limit,
sc->flags);
+ cpu_x86_dump_desc_flags(env, f, cpu_fprintf, sc->flags);
}
- cpu_fprintf(f, "LDT=%04x %08x %08x %08x\n",
+ cpu_fprintf(f, "LDT=%04x %08x %08x %08x",
env->ldt.selector,
(uint32_t)env->ldt.base,
env->ldt.limit,
env->ldt.flags);
- cpu_fprintf(f, "TR =%04x %08x %08x %08x\n",
+ cpu_x86_dump_desc_flags(env, f, cpu_fprintf, env->ldt.flags);
+ cpu_fprintf(f, "TR =%04x %08x %08x %08x",
env->tr.selector,
(uint32_t)env->tr.base,
env->tr.limit,
env->tr.flags);
+ cpu_x86_dump_desc_flags(env, f, cpu_fprintf, env->tr.flags);
cpu_fprintf(f, "GDT= %08x %08x\n",
(uint32_t)env->gdt.base, env->gdt.limit);
cpu_fprintf(f, "IDT= %08x %08x\n",
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [Qemu-devel] [RESEND][PATCH] x86: Enhanced dump of segment registers
2009-03-11 13:56 [Qemu-devel] [RESEND][PATCH] x86: Enhanced dump of segment registers Jan Kiszka
@ 2009-03-11 16:10 ` Jamie Lokier
2009-03-11 16:31 ` [Qemu-devel] " Jan Kiszka
2009-03-11 19:40 ` [Qemu-devel] [PATCH v2] " Jan Kiszka
1 sibling, 1 reply; 11+ messages in thread
From: Jamie Lokier @ 2009-03-11 16:10 UTC (permalink / raw)
To: qemu-devel
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?
Also I'm thinking the null descriptor doesn't need to show offset and
size:
FS =0000
is enough?
-- Jamie
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Qemu-devel] Re: [RESEND][PATCH] x86: Enhanced dump of segment registers
2009-03-11 16:10 ` Jamie Lokier
@ 2009-03-11 16:31 ` Jan Kiszka
2009-03-11 16:40 ` Jamie Lokier
2009-03-12 14:37 ` Avi Kivity
0 siblings, 2 replies; 11+ messages in thread
From: Jan Kiszka @ 2009-03-11 16:31 UTC (permalink / raw)
To: qemu-devel
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.
Thanks,
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] Re: [RESEND][PATCH] x86: Enhanced dump of segment registers
2009-03-11 16:31 ` [Qemu-devel] " Jan Kiszka
@ 2009-03-11 16:40 ` Jamie Lokier
2009-03-11 19:18 ` malc
2009-03-11 19:24 ` Jan Kiszka
2009-03-12 14:37 ` Avi Kivity
1 sibling, 2 replies; 11+ messages in thread
From: Jamie Lokier @ 2009-03-11 16:40 UTC (permalink / raw)
To: qemu-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] Re: [RESEND][PATCH] x86: Enhanced dump of segment registers
2009-03-11 16:40 ` Jamie Lokier
@ 2009-03-11 19:18 ` malc
2009-03-11 19:24 ` Jan Kiszka
1 sibling, 0 replies; 11+ messages in thread
From: malc @ 2009-03-11 19:18 UTC (permalink / raw)
To: qemu-devel
On Wed, 11 Mar 2009, 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?
The latter.
>
> 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
>
>
--
mailto:av1474@comtv.ru
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Qemu-devel] Re: [RESEND][PATCH] x86: Enhanced dump of segment registers
2009-03-11 16:40 ` Jamie Lokier
2009-03-11 19:18 ` malc
@ 2009-03-11 19:24 ` Jan Kiszka
1 sibling, 0 replies; 11+ messages in thread
From: Jan Kiszka @ 2009-03-11 19:24 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]
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. :)
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] Re: [RESEND][PATCH] x86: Enhanced dump of segment registers
2009-03-11 16:31 ` [Qemu-devel] " Jan Kiszka
2009-03-11 16:40 ` Jamie Lokier
@ 2009-03-12 14:37 ` Avi Kivity
2009-03-12 14:57 ` Jan Kiszka
1 sibling, 1 reply; 11+ messages in thread
From: Avi Kivity @ 2009-03-12 14:37 UTC (permalink / raw)
To: qemu-devel
Jan Kiszka wrote:
>> 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.
>
For gs and gs, base is meaningful even with null selectors (through
MSR_[FG]S_BASE or MSR_KERNEL_GS_BASE+swapgs).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Qemu-devel] Re: [RESEND][PATCH] x86: Enhanced dump of segment registers
2009-03-12 14:37 ` Avi Kivity
@ 2009-03-12 14:57 ` Jan Kiszka
2009-03-12 17:58 ` Jamie Lokier
0 siblings, 1 reply; 11+ messages in thread
From: Jan Kiszka @ 2009-03-12 14:57 UTC (permalink / raw)
To: qemu-devel
Avi Kivity wrote:
> Jan Kiszka wrote:
>>> 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.
>>
>
> For gs and gs, base is meaningful even with null selectors (through
> MSR_[FG]S_BASE or MSR_KERNEL_GS_BASE+swapgs).
>
I dropped any ideas to filter the output, -v2 is just a bug fix and code
refactoring.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] Re: [RESEND][PATCH] x86: Enhanced dump of segment registers
2009-03-12 14:57 ` Jan Kiszka
@ 2009-03-12 17:58 ` Jamie Lokier
2009-03-12 18:21 ` Jan Kiszka
0 siblings, 1 reply; 11+ messages in thread
From: Jamie Lokier @ 2009-03-12 17:58 UTC (permalink / raw)
To: qemu-devel
Jan Kiszka wrote:
> I dropped any ideas to filter the output, -v2 is just a bug fix and code
> refactoring.
The other thing I noticed, from your example, was LDT set to a null
selector but what might have been odd values in the descriptor cache
for LDT. I wonder if that's correct emulation behaviour?
-- Jamie
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Qemu-devel] Re: [RESEND][PATCH] x86: Enhanced dump of segment registers
2009-03-12 17:58 ` Jamie Lokier
@ 2009-03-12 18:21 ` Jan Kiszka
0 siblings, 0 replies; 11+ messages in thread
From: Jan Kiszka @ 2009-03-12 18:21 UTC (permalink / raw)
To: qemu-devel
Jamie Lokier wrote:
> Jan Kiszka wrote:
>> I dropped any ideas to filter the output, -v2 is just a bug fix and code
>> refactoring.
>
> The other thing I noticed, from your example, was LDT set to a null
> selector but what might have been odd values in the descriptor cache
> for LDT. I wonder if that's correct emulation behaviour?
The flags doesn't matter (they are set during CPU reset, but I'm even
unsure if there is any code evaluation them except cpu_dump_state). As
the limit is 0, any attempt to load a descriptor from that LDT will
raise an exception - on real hw as in the emulation.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Qemu-devel] [PATCH v2] x86: Enhanced dump of segment registers
2009-03-11 13:56 [Qemu-devel] [RESEND][PATCH] x86: Enhanced dump of segment registers Jan Kiszka
2009-03-11 16:10 ` Jamie Lokier
@ 2009-03-11 19:40 ` Jan Kiszka
1 sibling, 0 replies; 11+ messages in thread
From: Jan Kiszka @ 2009-03-11 19:40 UTC (permalink / raw)
To: qemu-devel
Parse the descriptor flags that segment registers refer to and show the
result in a more human-friendly format. The output of info registers eg.
then looks like this:
[...]
ES =007b 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0060 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
SS =0068 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
DS =007b 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0000 00000000 00000000 00000000
GS =0033 b7dd66c0 ffffffff b7dff3dd DPL=3 DS [-WA]
LDT=0000 00000000 00000000 00008200 DPL=0 LDT
TR =0080 c06da700 0000206b 00008900 DPL=0 TSS32-avl
[...]
Changes in this version:
- refactoring so that only a single helper is used for dumping the
segment descriptor cache
- tiny typo fixed that broke 64-bit segment type names
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
target-i386/cpu.h | 3 +-
target-i386/helper.c | 100 +++++++++++++++++++++++++++++++-------------------
2 files changed, 64 insertions(+), 39 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 90bceab..f38f194 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -82,9 +82,10 @@
#define DESC_AVL_MASK (1 << 20)
#define DESC_P_MASK (1 << 15)
#define DESC_DPL_SHIFT 13
-#define DESC_DPL_MASK (1 << DESC_DPL_SHIFT)
+#define DESC_DPL_MASK (3 << DESC_DPL_SHIFT)
#define DESC_S_MASK (1 << 12)
#define DESC_TYPE_SHIFT 8
+#define DESC_TYPE_MASK (15 << DESC_TYPE_SHIFT)
#define DESC_A_MASK (1 << 8)
#define DESC_CS_MASK (1 << 11) /* 1=code segment 0=data segment */
diff --git a/target-i386/helper.c b/target-i386/helper.c
index 8213703..5ce8798 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -570,6 +570,61 @@ static const char *cc_op_str[] = {
"SARQ",
};
+static void
+cpu_x86_dump_seg_cache(CPUState *env, FILE *f,
+ int (*cpu_fprintf)(FILE *f, const char *fmt, ...),
+ const char *name, struct SegmentCache *sc)
+{
+#ifdef TARGET_X86_64
+ if (env->hflags & HF_CS64_MASK) {
+ cpu_fprintf(f, "%-3s=%04x %016" PRIx64 " %08x %08x", name,
+ sc->selector, sc->base, sc->limit, sc->flags);
+ } else
+#endif
+ {
+ cpu_fprintf(f, "%-3s=%04x %08x %08x %08x", name, sc->selector,
+ (uint32_t)sc->base, sc->limit, sc->flags);
+ }
+
+ if (!(env->hflags & HF_PE_MASK) || !(sc->flags & DESC_P_MASK))
+ goto done;
+
+ cpu_fprintf(f, " DPL=%d ", (sc->flags & DESC_DPL_MASK) >> DESC_DPL_SHIFT);
+ if (sc->flags & DESC_S_MASK) {
+ if (sc->flags & DESC_CS_MASK) {
+ cpu_fprintf(f, (sc->flags & DESC_L_MASK) ? "CS64" :
+ ((sc->flags & DESC_B_MASK) ? "CS32" : "CS16"));
+ cpu_fprintf(f, " [%c%c", (sc->flags & DESC_C_MASK) ? 'C' : '-',
+ (sc->flags & DESC_R_MASK) ? 'R' : '-');
+ } else {
+ cpu_fprintf(f, (sc->flags & DESC_B_MASK) ? "DS " : "DS16");
+ cpu_fprintf(f, " [%c%c", (sc->flags & DESC_E_MASK) ? 'E' : '-',
+ (sc->flags & DESC_W_MASK) ? 'W' : '-');
+ }
+ cpu_fprintf(f, "%c]", (sc->flags & DESC_A_MASK) ? 'A' : '-');
+ } else {
+ static const char *sys_type_name[2][16] = {
+ { /* 32 bit mode */
+ "Reserved", "TSS16-avl", "LDT", "TSS16-busy",
+ "CallGate16", "TaskGate", "IntGate16", "TrapGate16",
+ "Reserved", "TSS32-avl", "Reserved", "TSS32-busy",
+ "CallGate32", "Reserved", "IntGate32", "TrapGate32"
+ },
+ { /* 64 bit mode */
+ "<hiword>", "Reserved", "LDT", "Reserved", "Reserved",
+ "Reserved", "Reserved", "Reserved", "Reserved",
+ "TSS64-avl", "Reserved", "TSS64-busy", "CallGate64",
+ "Reserved", "IntGate64", "TrapGate64"
+ }
+ };
+ cpu_fprintf(f, sys_type_name[(env->hflags & HF_LMA_MASK) ? 1 : 0]
+ [(sc->flags & DESC_TYPE_MASK)
+ >> DESC_TYPE_SHIFT]);
+ }
+done:
+ cpu_fprintf(f, "\n");
+}
+
void cpu_dump_state(CPUState *env, FILE *f,
int (*cpu_fprintf)(FILE *f, const char *fmt, ...),
int flags)
@@ -648,27 +703,15 @@ void cpu_dump_state(CPUState *env, FILE *f,
env->halted);
}
+ for(i = 0; i < 6; i++) {
+ cpu_x86_dump_seg_cache(env, f, cpu_fprintf, seg_name[i],
+ &env->segs[i]);
+ }
+ cpu_x86_dump_seg_cache(env, f, cpu_fprintf, "LDT", &env->ldt);
+ cpu_x86_dump_seg_cache(env, f, cpu_fprintf, "TR", &env->tr);
+
#ifdef TARGET_X86_64
if (env->hflags & HF_LMA_MASK) {
- for(i = 0; i < 6; i++) {
- SegmentCache *sc = &env->segs[i];
- cpu_fprintf(f, "%s =%04x %016" PRIx64 " %08x %08x\n",
- seg_name[i],
- sc->selector,
- sc->base,
- sc->limit,
- sc->flags);
- }
- cpu_fprintf(f, "LDT=%04x %016" PRIx64 " %08x %08x\n",
- env->ldt.selector,
- env->ldt.base,
- env->ldt.limit,
- env->ldt.flags);
- cpu_fprintf(f, "TR =%04x %016" PRIx64 " %08x %08x\n",
- env->tr.selector,
- env->tr.base,
- env->tr.limit,
- env->tr.flags);
cpu_fprintf(f, "GDT= %016" PRIx64 " %08x\n",
env->gdt.base, env->gdt.limit);
cpu_fprintf(f, "IDT= %016" PRIx64 " %08x\n",
@@ -685,25 +728,6 @@ void cpu_dump_state(CPUState *env, FILE *f,
} else
#endif
{
- for(i = 0; i < 6; i++) {
- SegmentCache *sc = &env->segs[i];
- cpu_fprintf(f, "%s =%04x %08x %08x %08x\n",
- seg_name[i],
- sc->selector,
- (uint32_t)sc->base,
- sc->limit,
- sc->flags);
- }
- cpu_fprintf(f, "LDT=%04x %08x %08x %08x\n",
- env->ldt.selector,
- (uint32_t)env->ldt.base,
- env->ldt.limit,
- env->ldt.flags);
- cpu_fprintf(f, "TR =%04x %08x %08x %08x\n",
- env->tr.selector,
- (uint32_t)env->tr.base,
- env->tr.limit,
- env->tr.flags);
cpu_fprintf(f, "GDT= %08x %08x\n",
(uint32_t)env->gdt.base, env->gdt.limit);
cpu_fprintf(f, "IDT= %08x %08x\n",
^ permalink raw reply related [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-03-12 18:21 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-11 13:56 [Qemu-devel] [RESEND][PATCH] x86: Enhanced dump of segment registers Jan Kiszka
2009-03-11 16:10 ` Jamie Lokier
2009-03-11 16:31 ` [Qemu-devel] " Jan Kiszka
2009-03-11 16:40 ` Jamie Lokier
2009-03-11 19:18 ` malc
2009-03-11 19:24 ` Jan Kiszka
2009-03-12 14:37 ` Avi Kivity
2009-03-12 14:57 ` Jan Kiszka
2009-03-12 17:58 ` Jamie Lokier
2009-03-12 18:21 ` Jan Kiszka
2009-03-11 19:40 ` [Qemu-devel] [PATCH v2] " Jan Kiszka
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).