local APIC Timer of AP problem (VMware vs. real CPU)

[WeirdCat]

I'm trying to enable the local APIC Timer of an AP. In VMware all works perfect, but on the three real 2-core CPUs I tried it, the local APIC Timer of the AP would not generate an actual interrupt. (BTW: The local APIC Timer of the BSP is working perfectly in VMware as well as on the real CPUs.)

I've checked that the local APIC of the AP is enabled in the IA32_APIC_BASE MSR and initialized the Timer with the following code:

Code: Select all

	mov	dword [0FEE003E0h], 0Bh	; Divide Configuration Register
	mov	dword [0FEE00380h], 27B9FBAh	; Initial Count Registers
	mov	dword [0FEE00320h], 20030h	; LVT Timer Register

I've also tried to enable the Symmetric I/O mode with the following code:

Code: Select all

	mov	al, 70h	; enable Symmetric I/O mode
	out	22h, al
	mov	al, 1
	out	23h, al

...with no effect.

Someone has an idea why this is working in VMware and not on real CPUs? What did I miss?

TIA,
Ash

[Hyperdrive]

I'm in a hurry, so just a few notes...

I'm trying to enable the local APIC Timer of an AP. In VMware all works perfect, but on the three real 2-core CPUs I tried it, the local APIC Timer of the AP would not generate an actual interrupt. (BTW: The local APIC Timer of the BSP is working perfectly in VMware as well as on the real CPUs.)

I've checked that the local APIC of the AP is enabled in the IA32_APIC_BASE MSR and initialized the Timer with the following code:

Code: Select all

	mov	dword [0FEE003E0h], 0Bh	; Divide Configuration Register
	mov	dword [0FEE00380h], 27B9FBAh	; Initial Count Registers
	mov	dword [0FEE00320h], 20030h	; LVT Timer Register

Seems okay to me. Are you sure, that your APs are up and running? Maybe there are issues in your startup code (IPI sequence and such) on real hardware.

I've also tried to enable the Symmetric I/O mode with the following code:

Code: Select all

	mov	al, 70h	; enable Symmetric I/O mode
	out	22h, al
	mov	al, 1
	out	23h, al

...with no effect.

You only should do this if the IMCR is implemented. If it's not, you don't know what this causes.

One more thing: You shouldn't assume the Local APICs are at 0xFEE00000. That's common, but you can't be sure.

For both things: Parse the BIOS tables (MPSpec or ACPI) to get the information.

--TS

[WeirdCat]

I'm in a hurry, so just a few notes...

Any help is appreciated.

Seems okay to me. Are you sure, that your APs are up and running? Maybe there are issues in your startup code (IPI sequence and such) on real hardware.

Yes, "they" (it's actually only one AP and one BSP - because I had only 2-core machines to test it ) are running fine. For testing purposes I let any core print it's TSC, an ID and some stats continuously on the screen.

You only should do this if the IMCR is implemented. If it's not, you don't know what this causes.
One more thing: You shouldn't assume the Local APICs are at 0xFEE00000. That's common, but you can't be sure.
For both things: Parse the BIOS tables (MPSpec or ACPI) to get the information.

In a later version I will definitely do this, for the moment it is enough for me to use the correct values.

[Combuster]

There are more than one bit that determine whether the APIC is enabled
Try the spurious interrupt vector register (intel 3A: Chapter 7.5 verse 14)

[Laksen]

Do you remember to enable the APIC after the AP has been booted?

[WeirdCat]

There are more than one bit that determine whether the APIC is enabled
Try the spurious interrupt vector register (intel 3A: Chapter 7.5 verse 14)

Yes, I thought I enabled that too (just forgot to mention it in my first posting). But you are right, the bug is in this line:

Code: Select all

	mov	dword [0FFE000F0h], 1FFh		; Spurious-Interrupt Vector Register

Thank you very much Combuster!

Hyperdrive: I will implement your suggestion right away! Hard coded costants are indeed very bad even in test environments. I've learned my lesson.

Thank you all for your help!