OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 4:36 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Adding SMP support
PostPosted: Mon May 17, 2021 8:56 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
CristiV wrote:
Well, I've loaded a GDT, using the example on this forum. Not an IDT, yet. But it still breaks somewhere.

Just knowing where it breaks could be enough to figure out the problem. Are you able to get GDB to step through the code?


Top
 Profile  
 
 Post subject: Re: Adding SMP support
PostPosted: Tue May 18, 2021 1:07 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3191
I can see several problems in the code. First, a far jmp is done to segment 8040, which is linear address 804000. Next, GDT is loaded based on the code being at 80xx, and finally, none of the selectors in the GDT are actually loaded, and so there is no use in loading the GDT in the first place. This results in 32-bit code being entered with real mode selectors still loaded, which is sure to tripple fault.


Top
 Profile  
 
 Post subject: Re: Adding SMP support
PostPosted: Tue May 18, 2021 1:15 am 
Offline

Joined: Wed May 12, 2021 4:08 am
Posts: 10
Ethin wrote:
What vector are you sending?


0x08 is the value of the vector

rdos wrote:
I can see several problems in the code. First, a far jmp is done to segment 8040, which is linear address 804000. Next, GDT is loaded based on the code being at 80xx, and finally, none of the selectors in the GDT are actually loaded, and so there is no use in loading the GDT in the first place. This results in 32-bit code being entered with real mode selectors still loaded, which is sure to tripple fault.


I just used the example provided on the wiki, to see if it would work. Someone said here that the lack of a GDT when switching to the protected mode leads to a triple fault.

I'm yet to fully understand how GDT, IDT and the real mode work


Top
 Profile  
 
 Post subject: Re: Adding SMP support
PostPosted: Tue May 18, 2021 1:50 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3191
CristiV wrote:
Ethin wrote:
What vector are you sending?


0x08 is the value of the vector

rdos wrote:
I can see several problems in the code. First, a far jmp is done to segment 8040, which is linear address 804000. Next, GDT is loaded based on the code being at 80xx, and finally, none of the selectors in the GDT are actually loaded, and so there is no use in loading the GDT in the first place. This results in 32-bit code being entered with real mode selectors still loaded, which is sure to tripple fault.


I just used the example provided on the wiki, to see if it would work. Someone said here that the lack of a GDT when switching to the protected mode leads to a triple fault.

I'm yet to fully understand how GDT, IDT and the real mode work


I think that is more or less a prerequisite for writing code like this. Real mode has 64k limits on all segments, and the linear address is formed by shifting the segment value four bits left and adding the offset. For protected mode, you load selectors from the GDT and the base & limit in the GDT determines how the linear address is calculated. To load a new CS selector, you must do a far jmp (or far call, ret, iret) to the selector. So, it's not enough to define flat selectors in the GDT, you also must load them. Of note is also that the default operand size is determined by the CS selector bitness, and real mode and 32-bit flat mode have different default operand sizes, and so if you do a far jmp through your flat selector, the code it jumps to needs to have 32-bit default bitness.


Top
 Profile  
 
 Post subject: Re: Adding SMP support
PostPosted: Wed May 19, 2021 9:37 am 
Offline
Member
Member

Joined: Sun Jun 23, 2019 5:36 pm
Posts: 618
Location: North Dakota, United States
CristiV wrote:
Ethin wrote:
What vector are you sending?


0x08 is the value of the vector

Someone correct me if I'm wrong, but I believe that that's not a valid interrupt. If memory serves the APIC/XAPIC/X2APIC can only send interrupts 0x10-0xFE, but anything below int 0x20 is a processor exception and should be avoided.


Top
 Profile  
 
 Post subject: Re: Adding SMP support
PostPosted: Wed May 19, 2021 1:42 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
Ethin wrote:
Someone correct me if I'm wrong, but I believe that that's not a valid interrupt.

It's not a valid interrupt for IPIs that use it as an interrupt vector, but it's valid for a STARTUP IPI. (I seem to recall a different set of vectors are considered invalid for SIPI, but I don't see it mentioned in the latest SDM.)


Top
 Profile  
 
 Post subject: Re: Adding SMP support
PostPosted: Sat Jun 19, 2021 12:34 am 
Offline

Joined: Wed May 12, 2021 4:08 am
Posts: 10
Update: I managed to get the APs in the long mode, I can run some C code on them, but I have 2 issues now:

I can run the
Code:
lock addl %esi, smp_aprunning
instruction, but not the
Code:
lock addq %rsi, smp_aprunning
instruction. Also, when going through the code with gdb, when it reaches an instruction like
Code:
mov    QWORD PTR [rbp-0x1b8],r8
it is converted to
Code:
mov    DWORD PTR [rbp-0x1b8],eax
Any idea why those happen?


Top
 Profile  
 
 Post subject: Re: Adding SMP support
PostPosted: Sat Jun 19, 2021 12:46 pm 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 1593
Sounds like your APs are in 32-bit mode, not 64-bit mode. Did you enable long mode on the APs?

_________________
Carpe diem!


Top
 Profile  
 
 Post subject: Re: Adding SMP support
PostPosted: Mon Jul 05, 2021 5:20 am 
Offline

Joined: Wed May 12, 2021 4:08 am
Posts: 10
New update: Everything works fine now. My thesis is complete, and I'll present it soon.
The problem I had was with the 64-bits GDT entry for the Code segment. That was putting my APs in the compatibility mode.

Thank you all for the help and patience!


Top
 Profile  
 
 Post subject: Re: Adding SMP support
PostPosted: Tue Jul 06, 2021 5:32 am 
Offline
Member
Member

Joined: Tue Feb 18, 2020 3:29 pm
Posts: 1071
CristiV wrote:
New update: Everything works fine now. My thesis is complete, and I'll present it soon.
The problem I had was with the 64-bits GDT entry for the Code segment. That was putting my APs in the compatibility mode.

Thank you all for the help and patience!

I hope you have the best of luck while presenting it!

_________________
"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg


Top
 Profile  
 
 Post subject: Re: Adding SMP support
PostPosted: Wed Dec 29, 2021 2:23 am 
Offline

Joined: Thu May 14, 2020 9:23 pm
Posts: 7
Hello CristiV,

Can you briefly explain how did you solve this problem? I seem to be facing the exact same problem where the AP CPU starts running but executes code at 0x1 instead of the trampoline vector that I specify.


Top
 Profile  
 
 Post subject: Re: Adding SMP support
PostPosted: Wed Dec 29, 2021 9:49 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
How did you determine it's running code at 0x1 instead of the correct address?


Top
 Profile  
 
 Post subject: Re: Adding SMP support
PostPosted: Wed Dec 29, 2021 11:31 pm 
Offline

Joined: Thu May 14, 2020 9:23 pm
Posts: 7
My trampoline code is located at address 0x8000. I see the AP $eip infinitely switch between address 0x0 and 0x1.

Dump of registers on the AP:
Code:
(gdb) info registers
eax            0x0                 0
ecx            0x0                 0
edx            0x663               1635
ebx            0x0                 0
esp            0x0                 0x0
ebp            0x0                 0x0
esi            0x0                 0
edi            0x0                 0
eip            0x1                 0x1
eflags         0x2                 [ IOPL=0 ]
cs             0x800               2048
ss             0x0                 0
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0
fs_base        0x0                 0
gs_base        0x0                 0
k_gs_base      0x0                 0
cr0            0x60000010          [ CD NW ET ]
cr2            0x0                 0
cr3            0x0                 [ PDBR=0 PCID=0 ]
cr4            0x0                 [ ]
cr8            0x0                 0
efer           0x0                 [ ]


Edit:
Actually, I went through this thread again and stumbled upon your earlier post where you said:
"Are you sure the problem isn't GDB? Last I checked, it assumes the CS base is always 0, so it displays nonsense when the CPU is in real mode with CS set to any nonzero value."

I think, like you said, I am seeing garbage/incorrect $eip because I am trying to debug code in real mode.


Top
 Profile  
 
 Post subject: Re: Adding SMP support
PostPosted: Thu Dec 30, 2021 4:10 am 
Offline

Joined: Thu May 14, 2020 9:23 pm
Posts: 7
Update:
That was it. I have the AP boot up and working now. I wasted too much time on this.

Thanks Octocontrabass and everyone involved in this thread.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], nullpointer and 53 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group