The Interrupt Command Register

[fluray]

Hi,guys!
I have a problem about BSP broadcast SIPI(Startup IPI).
In pure64 project's source code(init_smp.asm):

Code: Select all

   mov rsi, 0x0000000000005100 ; All Local APIC ID is stored 
   xor ecx, ecx
   mov cx, [cpu_detected]         ; Logical CPU number
smp_send_SIPI:
   cmp cx, 0
   je smp_send_SIPI_done
   lodsb
                            ; BSP APIC ID in DL
   cmp al, dl            ; Is it the BSP?   
   je smp_send_SIPI_skipcore

   ; Broadcast 'Startup' IPI to destination using vector 0x08 to specify entry-point is at the memory-address 0x00008000
   mov rdi, [os_LocalAPICAddress]
   shl eax, 24                     ; eax : AP's Local APIC ID
   mov dword [rdi+0x310], eax      ; Interrupt Command Register (ICR); bits 63-32
   mov eax, 0x00004608               ; Vector 0x08
   mov dword [rdi+0x300], eax      ; Interrupt Command Register (ICR); bits 31-0
smp_send_SIPI_verify:
   mov eax, [rdi+0x300]          ; Interrupt Command Register (ICR); bits 31-0
   bt eax, 12                         ; Verify that the command completed
   jc smp_send_SIPI_verify

smp_send_SIPI_skipcore:
   dec cl
   jmp smp_send_SIPI   

smp_send_SIPI_done:

BSP: Broadcast 'Startup' IPI to destination using vector 0x08 to specify entry-point is at the memory-address 0x00008000(AP code entry)
Adress 0x8000 is the entry of AP code . The vector 0x08 is set to the DF exception when initialized, it's interrupt handler only outputs some strings and hang.
Why the vectors 0x08 used in the ICR(interrupt comand register) can jump to the address of 0x8000?

My english is not very good , but i am working on it .
Thanks in advance!

[thepowersgang]

Oddly, the vector sent with the INIT IPI is not an interrupt vector, it's actually the address you want to start at divided by 0x1000. It can't be an interrupt number, because at that time the state of the BSP's IDT is completely unknown.

[fluray]

Oddly, the vector sent with the INIT IPI is not an interrupt vector, it's actually the address you want to start at divided by 0x1000. It can't be an interrupt number, because at that time the state of the BSP's IDT is completely unknown.

Thank you for your guidance.I have got it.
but I don't think your idea of the sentence "BSP's IDT is completely unknown" is right.
I saw two examples, are executed initialization smp after entering protected mode.
pure64.asm：

Code: Select all

	; Set up the exception gates for all of the CPU exceptions
	mov word [0x00*16], exception_gate_00
	mov word [0x01*16], exception_gate_01
	mov word [0x02*16], exception_gate_02
	mov word [0x03*16], exception_gate_03
	mov word [0x04*16], exception_gate_04
	mov word [0x05*16], exception_gate_05
	mov word [0x06*16], exception_gate_06
	mov word [0x07*16], exception_gate_07
	mov word [0x08*16], exception_gate_08
	mov word [0x09*16], exception_gate_09
	mov word [0x0A*16], exception_gate_10
	mov word [0x0B*16], exception_gate_11
	mov word [0x0C*16], exception_gate_12
	mov word [0x0D*16], exception_gate_13
	mov word [0x0E*16], exception_gate_14
	mov word [0x0F*16], exception_gate_15
	mov word [0x10*16], exception_gate_16
	mov word [0x11*16], exception_gate_17
	mov word [0x12*16], exception_gate_18
	mov word [0x13*16], exception_gate_19

	mov rdi, 0x21			; Set up Keyboard IRQ handler
	mov rax, keyboard
	call create_gate	
	mov rdi, 0x28			; Set up RTC IRQ handler
	mov rax, rtc
	call create_gate
	mov rdi, 0xF8			; Set up Spurious handler
	mov rax, spurious
	call create_gate

	lidt [IDTR64]			; load IDT register

; Clear memory 0xf000 - 0xf7ff for the infomap (2048 bytes)
	xor rax, rax
	mov rcx, 256
	mov rdi, 0x000000000000F000
clearmapnext:
	stosq
	dec rcx
	cmp rcx, 0
	jne clearmapnext

	call init_acpi			; Find and process the ACPI tables
	call init_cpu			; Setup CPU
	call init_ioapic		; Setup the IO-APIC(s), also activate interrupts

	call hdd_setup			; Gather Hard Drive information
	mov al, 1
	mov byte [cfg_default], al	; We have a config file
; Init of SMP
	call smp_setup          ;init_smp.asm

[thepowersgang]

Hmm... it did sound a little strange when I typed it. Odds are it is the real mode IVT (that said, afaik it's possible that the CPU is in protected mode at the point it gets that message, depends on if it's been reset in the meantime. Working off memory here, so don't quote me on it)

[Bender]

From what I vaguely remember Pure64 uses the BIOS to initialize the serial, video (if configured), and sets up A20 using the BIOS, after it enters Long Mode it exploits the area from 0x0000 to 0x4FFFF (linear).
This isn't good because it exploits the BDA and the IVT which could've been used by the OS after boot (Video Mode Switching etc.). This is confirmed by the following lines from https://github.com/ReturnInfinity/Pure6 ... pure64.asm

Code: Select all

mov ecx, 1024
	xor eax, eax
	mov edi, eax
	rep stosd

As you see the code above exploits the Lower 1 MB half, and potentially destroying the BDA. I wonder if anyone has reported the bug to ReturnInfinity yet. IMO 0x500 to 0x7FFFF (Almost 512KB of RAM IIRC) should be used instead, the only portion I would say is "so-called unusable" will be 0x7C00, but that's 512 bytes and I don't think there should be a large problem when erasing the boot sector from memory. This must be along with the system memory map though.