ltr exception (bochs)

staringlizard · **Joined:** Wed Aug 13, 2014 1:15 pm **Posts:** 15

Hi All,

I get below errors when running bochs with my kernel (x86-64).

Code:

00156933951d[CPU0  ] inhibit interrupts mask = 3
00156933960e[CPU0  ] fetch_raw_descriptor64: extended attributes DWORD4 TYPE != 0
00156933960d[CPU0  ] exception(0x0d): error_code=0028
00156933960d[CPU0  ] interrupt(): vector = 0d, TYPE = 3, EXT = 1
00156933960e[CPU0  ] interrupt(long mode): IDT entry extended attributes DWORD4 TYPE != 0
00156933960d[CPU0  ] exception(0x0d): error_code=006a
00156933960d[CPU0  ] exception(0x08): error_code=0000
00156933960d[CPU0  ] interrupt(): vector = 08, TYPE = 3, EXT = 1
00156933960e[CPU0  ] interrupt(long mode): IDT entry extended attributes DWORD4 TYPE != 0
00156933960d[CPU0  ] exception(0x0d): error_code=0042
00156933960i[CPU0  ] CPU is in long mode (active)
00156933960i[CPU0  ] CS.mode = 64 bit
00156933960i[CPU0  ] SS.mode = 64 bit
00156933960i[CPU0  ] EFER   = 0x00000500
00156933960i[CPU0  ] | RAX=000000000000002b  RBX=0000000000000000
00156933960i[CPU0  ] | RCX=00000000c0000080  RDX=0000000000000010
00156933960i[CPU0  ] | RSP=000000000000efc4  RBP=0000000000000000
00156933960i[CPU0  ] | RSI=00408900060000a0  RDI=000000000000002b
00156933960i[CPU0  ] |  R8=0000000000000000   R9=0000000000000000
00156933960i[CPU0  ] | R10=00000000000082f5  R11=0000000000000000
00156933960i[CPU0  ] | R12=0000000000000000  R13=0000000000000000
00156933960i[CPU0  ] | R14=0000000000000000  R15=0000000000000000
00156933960i[CPU0  ] | IOPL=0 id vip vif ac vm RF nt of df if tf sf zf af pf cf
00156933960i[CPU0  ] | SEG sltr(index|ti|rpl)     base    limit G D
00156933960i[CPU0  ] |  CS:0008( 0001| 0|  0) 00000000 00000000 0 0
00156933960i[CPU0  ] |  DS:0010( 0002| 0|  0) 00000000 00000000 0 0
00156933960i[CPU0  ] |  SS:0010( 0002| 0|  0) 00000000 00000000 0 0
00156933960i[CPU0  ] |  ES:0010( 0002| 0|  0) 00000000 00000000 0 0
00156933960i[CPU0  ] |  FS:0010( 0002| 0|  0) 00000000 00000000 0 0
00156933960i[CPU0  ] |  GS:0010( 0002| 0|  0) 00000000 00000000 0 0
00156933960i[CPU0  ] |  MSR_FS_BASE:0000000000000000
00156933960i[CPU0  ] |  MSR_GS_BASE:0000000000000000
00156933960i[CPU0  ] | RIP=0000000000008ab5 (0000000000008ab5)
00156933960i[CPU0  ] | CR0=0xe0000011 CR2=0x0000000000000000
00156933960i[CPU0  ] | CR3=0x00002000 CR4=0x000000b0
00156933960i[CPU0  ] 0x0000000000008ab5>> ltr ax : 0F00D8
00156933960e[CPU0  ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting

My code works with qemu and with a normal laptop.

I have 5 gdt starting at 0x500. They look like below
(in the order NULL, KRN_CODE, KRN_DATA, USER_CODE, USER_DATA, TSS):

Code:

(gdb) p/x *(unsigned long *)0x500
$9 = 0x0
(gdb) p/x *(unsigned long *)0x508
$10 = 0x20980000000000
(gdb) p/x *(unsigned long *)0x510
$11 = 0x930000000000
(gdb) p/x *(unsigned long *)0x518
$12 = 0x20f80000000000
(gdb) p/x *(unsigned long *)0x520
$13 = 0x920000000000
(gdb) p/x *(unsigned long *)0x528
$14 = 0x408900060000a0
(gdb) 

TSS is located at 0x600 and is length 0xa0

GDT pointer looks like this:

Code:

(gdb) p/x hal_cpu_config_gdtp
$16 = {limit = 0x37, base = 0x500}
(gdb) p/x &hal_cpu_config_gdtp
$17 = 0x16018

So I will first setup all descriptors including tss and call "lgdt [gdt_address]".
The TSS is the fifth position so I will load this with:

asm("mov %0, %%rax":: "r"((u64_t)segment_offset));
asm("ltrw %%ax":);

(or just plain "ltr $0x2b")

When I do this bochs will restart. If not then everything is dandy.

Does anyone know what I am doing wrong?

Regards,
StaringL

stlw · **Joined:** Fri Apr 04, 2008 6:43 am **Posts:** 357

I could only tell what the error message mean: "extended attributes DWORD4 TYPE != 0".
in 64-bit mode descriptors are 16-byte (4 dwords). The 4th DWORD should be always ZERO but it isn't in your case.

Stanislav

KemyLand · **Posted:** Sun Nov 16, 2014 5:15 pm

Are you sure your TSS is valid? All x86 CPUs are programmed to #PF when a reserved bit is set. I see that you're loading an GDT segment. See this list (32-bit):

Off 0x00: Null entry
Off 0x08: 1st entry
Off 0x10: 2nd entry
Off 0x16: 3rd entry
Off 0x20: 4th entry
Off 0x28: 5th entry

Enough! 0x2B points nowhere by there... See this other list (According to stlw):

Off 0x00: Null entry
Off 0x10: 1st entry
Off 0x20: 2nd entry
Off 0x30: 3rd entry

Enough! You seem to be pointing to an invalid descriptor, eh? Why are you passing 0x2B, when it's 0x28?

stlw wrote:

I could only tell what the error message mean: "extended attributes DWORD4 TYPE != 0".
in 64-bit mode descriptors are 16-byte (4 dwords). The 4th DWORD should be always ZERO but it isn't in your case.

Stanislav

I'm not really sure if what you say is true, as even his GDB is telling another story...

Another possible issue is the fact that you're not using the clobbered registers list. Also, you should use volatile when inline assembling. Change

Code:

asm("mov %0, %%rax":: "r"((u64_t)segment_offset));
asm("ltrw %%ax":);

For

Code:

volatile asm("mov %0, %%rax; ltrw %%ax"::"r"((u64)segment_offset):"%rax");

Try this and tell us your results :wink:

.

Brendan · **Posted:** Sun Nov 16, 2014 8:36 pm

Hi,

staringlizard wrote:

(or just plain "ltr $0x2b")

That would mean "the entry at offset 0x0028 in the GDT, with CPL=3. CPL=3 doesn't make sense for TSSs (as the CPL comes from the "CS" field in the TSS). I'm not sure if the CPU is supposed to ignore the lowest 2 bits or generate a GPF in this case.

staringlizard wrote:

(gdb) p/x *(unsigned long *)0x528
$14 = 0x408900060000a0

That decodes as:

0x00A0 = lowest 16 bits of limit
0x000600 = lowest 24 bits of base
0x89 = present, DPL=3, 64-bit TSS
0x0 = bits 16 to 19 of limit
0x4 = byte granularity, reserved flag that must be 0 is set
0x00 = bits 24 to 31 of base

Because it's a 64-bit TSS, it's supposed to have a 64-bit base. Bits 32 to 63 of the base address are in the next dword at offset 0x0030 in the GDT. This dword wasn't shown.

The dword after that (at offset 0x0034) is reserved and must be zero (this is the dword that Stanislav is talking about). It wasn't shown either.

This means there's between 1 and 3 potential causes for GPF (the reserved bit that's set in the "0x4 nibble", plus maybe the dodgy 0x2B with a CPL that doesn't make sense, plus maybe the reserved dword at offset 0x0034 that may be non-zero).

Of course if Stanislav (one of the main Bochs developers) says that the error message means the dword at 0x0034 wasn't zero, then it's extremely likely that the dword at offset 0x0034 (which wasn't shown) wasn't zero.

Cheers,

Brendan

staringlizard · **Joined:** Wed Aug 13, 2014 1:15 pm **Posts:** 15

Brendan wrote:

That would mean "the entry at offset 0x0028 in the GDT, with CPL=3. CPL=3 doesn't make sense for TSSs (as the CPL comes from the "CS" field in the TSS). I'm not sure if the CPU is supposed to ignore the lowest 2 bits or generate a GPF in this case.

I was looking at James Molloys site:
http://www.jamesmolloy.co.uk/tutorial_h ... 0Mode.html

He say:

Code:

[GLOBAL tss_flush]    ; Allows our C code to call tss_flush().
tss_flush:
   mov ax, 0x2B      ; Load the index of our TSS structure - The index is
                     ; 0x28, as it is the 5th selector and each is 8 bytes
                     ; long, but we set the bottom two bits (making 0x2B)
                     ; so that it has an RPL of 3, not zero.
   ltr ax            ; Load 0x2B into the task state register.
   ret

Brendan wrote:

Because it's a 64-bit TSS, it's supposed to have a 64-bit base. Bits 32 to 63 of the base address are in the next dword at offset 0x0030 in the GDT. This dword wasn't shown.

The dword after that (at offset 0x0034) is reserved and must be zero (this is the dword that Stanislav is talking about). It wasn't shown either.

You are right! There was some junk at the offset 0x0030 which was not supposed to be there.

I was not aware that the TSS in x86-64 (as opposed to the other GDT entries which are only 8 bytes) should be 16 bytes :oops:

Intel® 64 and IA-32 Architectures Software Developer’s Manual wrote:

7.2.3 TSS Descriptor in 64-bit mode
In 64-bit mode, task switching is not supported, but TSS descriptors still exist. The format of a 64-bit TSS is
described in Section 7.7.
In 64-bit mode, the TSS descriptor is expanded to 16 bytes (see Figure 7-4). This expansion also applies to an LDT
descriptor in 64-bit mode. Table 3-2 provides the encoding information for the segment type field.

Thanks Eveyone !

Regards,
StaringL

OSDev.org

ltr exception (bochs)

Who is online