Adding SMP support

[Octocontrabass]

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?

[rdos]

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.

[CristiV]

What vector are you sending?

0x08 is the value of the vector

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

[rdos]

What vector are you sending?

0x08 is the value of the vector

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.

[Ethin]

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.

[Octocontrabass]

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

[CristiV]

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: Select all

lock addl %esi, smp_aprunning

instruction, but not the

Code: Select all

lock addq %rsi, smp_aprunning

instruction. Also, when going through the code with gdb, when it reaches an instruction like

Code: Select all

mov    QWORD PTR [rbp-0x1b8],r8

it is converted to

Code: Select all

mov    DWORD PTR [rbp-0x1b8],eax

Any idea why those happen?

[nullplan]

Sounds like your APs are in 32-bit mode, not 64-bit mode. Did you enable long mode on the APs?

[CristiV]

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!

[nexos]

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!

[crescent]

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.

[Octocontrabass]

How did you determine it's running code at 0x1 instead of the correct address?

[crescent]

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: Select all

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

[crescent]

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.