Page 1 of 2
tss and ltr?
Posted: Tue Jul 19, 2005 11:48 pm
by northfuse
i have software task switching working fine when all the tasks are in ring0. I'm trying to get user tasks working, but i can't figure out how to add the TSS to the GDT. I know you use the LTR, but i can't figure it out. Any help would be great!
Re:tss and ltr?
Posted: Wed Jul 20, 2005 2:31 am
by AR
You have a TSS GDT Descriptor which says where to find the TSS then you have the TSS itself where you fill out ESP0 and SS0 (and use the Bitmap if you want) then you execute LTR to load the TSS into the Task Register.
Re:tss and ltr?
Posted: Mon Aug 01, 2005 5:47 am
by calpis
Hi,
I have problem when I set the TR to initialise the TSS.
I have the TSS in GDT, and a TSS struct.
When I start up bochs, it worked until it runs the settr(24). Bochs reboot. Any idea?
Thanks in advance
Re:tss and ltr?
Posted: Mon Aug 01, 2005 8:12 am
by AR
The only thing that comes to mind is a bad GDT Descriptor, or a too small TSS (both of which would cause a GPF IIRC).
Re:tss and ltr?
Posted: Mon Aug 01, 2005 9:03 am
by HardEnough
i heard that TSS changed automatically by calls or far jumps is it right ?
Re:tss and ltr?
Posted: Mon Aug 01, 2005 3:49 pm
by calpis
I suppose I have done nothing wrong in the GDT entry. May be its my kmalloc which I improved awhile ago which gives out a page of physical memory. here is the result from kprintf anyway.
Result from kprintf:
The base015 is 3FD000h which is the first free page on the stack.
The base1623 is 3Fh
The base 2431 is 0h
The limit is 0x67h
Code: Select all
tss = kmalloc(sizeof(struct task_state)) ; //struct tss_entry tss[3];
gdt[3].limit =sizeof(struct task_state)-1;
gdt[3].base015 =(int) tss;
gdt[3].base1623=(int) tss >>16;
gdt[3].access =0x89;//0x80+0x9
gdt[3].granularity=0;
gdt[3].base2431=(int)tss>>24;
kprintf("TSS GDT entry (Base(015):%h base(1623):%h base(2431):%h,Limit:%h\n", (int)tss,((int)tss>>16),((int)tss>>24),sizeof(struct task_state) -1);
Thanks in advance.
Re:tss and ltr?
Posted: Mon Aug 01, 2005 9:08 pm
by AR
HardEnough wrote:i heard that TSS changed automatically by calls or far jumps is it right ?
When a task is switched during hardware task switching, the current state is automatically saved to the TSS, this is actually slower than doing it manually for some reason though.
In software task switching with only 1 TSS it should never be changed automatically (although if you start multitasking be far jumping to the TSS, the CPU will change the descriptor to "Busy TSS" which will cause a problem if you try to far jump to the same TSS again.
@chaisu chase: base015 should be "D000" although it's actually a 24bit integer so that shouldn't be a problem (you just printed wrong, I hope). I'm not sure about the rest as I don't have my reference material at hand. It would be helpful if you posted the structs you use for the GDT Descriptor and the TSS itself though.
Re:tss and ltr?
Posted: Tue Aug 02, 2005 5:38 am
by calpis
3FD000 was at the top of the free page stack. I am only mapped the first directory hence returned this address. 3FE000 and 3FF000 are used for my free page stack, and used page stack.
after kmalloc 3FD000 is popped and push on the used page stack.
When I kmalloc the TSS in my GDT, that address is been allocated.
I was told that in paging, we are dealing with virtual address. But when I did my kmalloc, i think I am getting comfuse with the virtual address and phyiscal address. But I wasn't sure if my kmalloc its right.
It builds a page stack and (binded with dir & page & offset) before I push them to the stacks(hence these are physical address...I think).
I pop a free page off the free page stack and push it on to the used page stack.
And return the result address which is the address allocated to TSS. I think there is something wrong with it which course the tss error. In case if you want to see the kmalloc code. Here is the link.
http://www.mega-tokyo.com/forum/index.p ... 3#msg68453
And here is the struct GDT and TSS.
Code: Select all
struct gdt_descriptor
{
unsigned short limit;
unsigned short base015;
unsigned char base1623;
unsigned char access;
unsigned char granularity;
unsigned char base2431;
}__attribute__((packed));
struct gdt_ptr
{
unsigned short limit;
unsigned int base;
}__attribute__((packed));
struct gdt_descriptor gdt[4];
/* 3 gdt entry and special gdt pointer */
struct gdt_ptr gdtr[1];
extern void gdt_flush();
/*a function we will use from start.asm reload the new segment register*/
struct task_state
{
short backlink, __blh;
int esp0;
short ss0, __ss0h;
int esp1;
short ss1, __ss1h;
int esp2;
short ss2, __ss2h;
int cr3;
int eip;
int eflags;
int eax, ecx, edx, ebx;
int esp, ebp, esi, edi;
short es, __esh;
short cs, __csh;
short ss, __ssh;
short ds, __dsh;
short fs, __fsh;
short gs, __gsh;
short ldt, __ldth;
short trace, bitmap;
};
//Haven't use this yet.
struct tss_entry //I should be in either struct.h or tss.h
{
short res1; //code
short selector;
char res2 ; //data
char type;
short res3; //stack
}__attribute__((packed));
Thanks in advance
Re:tss and ltr?
Posted: Tue Aug 02, 2005 7:16 am
by AR
The thing that flies out is that you're missing __attribute__((packed)) on the TSS struct. I can't see anything else wrong (I'm not sure if you need the "- 1" on the size).
Re:tss and ltr?
Posted: Tue Aug 02, 2005 5:40 pm
by calpis
It still doesn't work after I put __attribute__((packed) in the struct. So you don't think its the kmalloc right?
This is what bochs tells me before it reboots. anything clues from here? I noticed that I had 2 extra line in the bochsout. The selector and gdtr.limit. I mean where is this selector->index, and what is it?
Code: Select all
00042926100i[CPU ] -----------------------------------
00042926100i[CPU ] selector->index*8 + 7 = 31
00042926100i[CPU ] gdtr.limit = 23
00042926100i[CPU ] fetch_raw_descriptor: GDT: index > limit
00042926100i[CPU ] | EAX=00000007 EBX=003fd000 ECX=00000000 EDX=000003d5
00042926100i[CPU ] | ESP=00103b18 EBP=00103b18 ESI=0002cb46 EDI=0002cb47
00042926100i[CPU ] | IOPL=0 NV UP DI PL NZ NA PO NC
00042926100i[CPU ] | SEG selector base limit G D
00042926100i[CPU ] | SEG sltr(index|ti|rpl) base limit G D
00042926100i[CPU ] | DS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00042926100i[CPU ] | ES:0010( 0002| 0| 0) 00000000 000fffff 1 1
00042926100i[CPU ] | FS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00042926100i[CPU ] | GS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00042926100i[CPU ] | SS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00042926100i[CPU ] | CS:0008( 0001| 0| 0) 00000000 000fffff 1 1
00042926100i[CPU ] | EIP=00101c95 (00101c91)
00042926100i[CPU ] | CR0=0xe0000011 CR1=0x00000000 CR2=0x00000000
00042926100i[CPU ] | CR3=0x0009c000 CR4=0x00000000
00042926100i[CPU ] -----------------------------------
00042926100e[CPU ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting
Thanks in advance
Re:tss and ltr?
Posted: Tue Aug 02, 2005 6:44 pm
by AR
That says that your GDT does not contain the entry you are trying to use, I suggest you check your initalization code to make sure you're using the right selector with LTR and also including that descriptor entry in the GDT to begin with.
Re:tss and ltr?
Posted: Tue Aug 02, 2005 7:11 pm
by calpis
This is my tr.
and I did a settr(24). It then keeps rebooting. And which initialization cod e did you mean? I don't know if 24 is the right selector. How can I tell which is selector am I using?
Code: Select all
settr:
push ebp
mov ebp, esp
ltr [EBP + 8]
pop ebp
ret
Thanks
Re:tss and ltr?
Posted: Tue Aug 02, 2005 7:46 pm
by AR
Ok, according to Bochs the GDT is 24 bytes long, entry number 24 [0x18] is after the end of the GDT. Check your initalizer for the GDT itself, the code you use for running LGDT is not making the "limit" large enough to cover gdt[3].
Re:tss and ltr?
Posted: Tue Aug 02, 2005 7:59 pm
by calpis
Aha~! Genius~! Thanks AR for spotting it!!!
my gdtr was indeed for 3 entries only! I changed to 4 and it worked.
Thanks so much~!
Re:tss and ltr?
Posted: Sun Aug 07, 2005 2:29 pm
by northfuse
I keep getting the error LTR: doesn't point to a valid TSS descriptor. I used the code that chaisu chase used, but it doesn't seem to work.