Skip to contentSkip to conversation

enable x2APIC without interrupt remapping under KVM

PATCH Superseded Gleb Natapov 3 participants 6 messages Jun 29, 2009

Subsystems (2)

v2 of 5 Superseded Latest is v5 →

lore
Share & tools
lore
#0 lore raw

PATCH v2 1/1 enable x2APIC without interrupt remapping under KVM

KVM would like to provide x2APIC interface to a guest without emulating interrupt remapping device. The reason KVM prefers guest to use x2APIC is that x2APIC interface is better virtualizable and provides better performance than mmio xAPIC interface:

- msr exits are faster than mmio (no page table walk, emulation)
- no need to read back ICR to look at the busy bit
- one 64 bit ICR write instead of two 32 bit writes
- shared code with the Hyper-V paravirt interface

Included patch changes x2APIC enabling logic to enable it even if IR initialization failed, but kernel runs under KVM and no apic id is greater than 255 (if there is one spec requires BIOS to move to x2apic mode before starting an OS).

---

v2:
Add help message to Kconfig
Force physical mode if IR is not available.

arch/x86/Kconfig +5 -2
index d1430ef..3e5b6ea 100644
@@ -260,12 +260,15 @@ config SMP
 
 config X86_X2APIC
 	bool "Support x2apic"
-	depends on X86_LOCAL_APIC && X86_64 && INTR_REMAP
+	depends on X86_LOCAL_APIC && X86_64
 	---help---
 	  This enables x2apic support on CPUs that have this feature.
 
 	  This allows 32-bit apic IDs (so it can support very large systems),
-	  and accesses the local apic via MSRs not via mmio.
+	  and accesses the local apic via MSRs not via mmio. CONFIG_INTR_REMAP
+	  is required for x2apic to take affect when running on physical
+	  machine. If you intend to run the kernel as KVM guest x2apic can
+	  be used without interrupt remapping.
 
 	  If you don't know what to do here, say N.
 
arch/x86/kernel/apic/apic.c +45 -26

124 lines not on this page · raw message

--
Gleb.

#1 lore raw
Quoted 27 lines · Gleb Natapov

KVM would like to provide x2APIC interface to a guest without emulating interrupt remapping device. The reason KVM prefers guest to use x2APIC is that x2APIC interface is better virtualizable and provides better performance than mmio xAPIC interface:

- msr exits are faster than mmio (no page table walk, emulation)
- no need to read back ICR to look at the busy bit
- one 64 bit ICR write instead of two 32 bit writes
- shared code with the Hyper-V paravirt interface

Included patch changes x2APIC enabling logic to enable it even if IR initialization failed, but kernel runs under KVM and no apic id is greater than 255 (if there is one spec requires BIOS to move to x2apic mode before starting an OS).

---

v2:
Add help message to Kconfig
Force physical mode if IR is not available.

arch/x86/Kconfig +0 -0
index d1430ef..3e5b6ea 100644

arch/x86/Kconfig config SMP · line 263

Quoted 5 lines
arch/x86/Kconfig +1 -1
@@ -260,12 +260,15 @@ config SMP
 
 config X86_X2APIC
 	bool "Support x2apic"
-	depends on X86_LOCAL_APIC && X86_64 && INTR_REMAP
+	depends on X86_LOCAL_APIC && X86_64

Have you tried to build this with X86_X2APIC set but INTR_REMAP disabled?

Ingo

#2 lore raw
Quoted 31 lines · Ingo Molnar
Quoted 28 lines · Gleb Natapov

KVM would like to provide x2APIC interface to a guest without emulating interrupt remapping device. The reason KVM prefers guest to use x2APIC is that x2APIC interface is better virtualizable and provides better performance than mmio xAPIC interface:

- msr exits are faster than mmio (no page table walk, emulation)
- no need to read back ICR to look at the busy bit
- one 64 bit ICR write instead of two 32 bit writes
- shared code with the Hyper-V paravirt interface

Included patch changes x2APIC enabling logic to enable it even if IR initialization failed, but kernel runs under KVM and no apic id is greater than 255 (if there is one spec requires BIOS to move to x2apic mode before starting an OS).

---

v2:
Add help message to Kconfig
Force physical mode if IR is not available.

arch/x86/Kconfig +0 -0
index d1430ef..3e5b6ea 100644
@@ -260,12 +260,15 @@ config SMP
 
Quoted 8 lines

arch/x86/Kconfig config SMP · line 263

Quoted 4 lines
arch/x86/Kconfig +1 -1
 config X86_X2APIC
 	bool "Support x2apic"
-	depends on X86_LOCAL_APIC && X86_64 && INTR_REMAP
+	depends on X86_LOCAL_APIC && X86_64

Have you tried to build this with X86_X2APIC set but INTR_REMAP disabled?

Yes. I notice that X86_X2APIC depends on INTR_REMAP when I did it.

--
Gleb.

#3 lore raw
In reply to Gleb Natapov

arch/x86/kernel/apic/apic.c void __init enable_IR_x2apic(void) · line 1405

Quoted 4 lines · Gleb Natapov
arch/x86/kernel/apic/apic.c +0 -2
-	local_irq_save(flags);
 	mask_IO_APIC_setup(ioapic_entries);
-	mask_8259A();

Is there a reason why the 8259 mask/unmask operations are separated from io-apic mask/unmask operations.

Can we keep it together so that it will be easy to read and understand that we first do the interrupt subsystem mask, try enabling IR and x2apic and unmask the interrupt subsystem.

Otherwise I am ok with this change.

thanks,
suresh

#4 lore raw
Quoted 9 lines · Suresh Siddha

arch/x86/kernel/apic/apic.c void __init enable_IR_x2apic(void) · line 1405

Quoted 4 lines · Gleb Natapov
arch/x86/kernel/apic/apic.c +0 -2
-	local_irq_save(flags);
 	mask_IO_APIC_setup(ioapic_entries);
-	mask_8259A();

Is there a reason why the 8259 mask/unmask operations are separated from io-apic mask/unmask operations.

I left interrupt masking in enable_IR_x2apic() because interrupt should be masked during transition to x2apic mode, so it can't be moved to enable_IR(). I moved io-apic into enable_IR() because the state of io-apic depend on whether IR was enabled or not, so I left it close to IR enabling logic. Also io-apic masking can fail, but we still want to enable x2apic on KVM if possible, and moving io-apic masking to enable_IR_x2apic() will complicate the logic.

Quoted 4 lines

Can we keep it together so that it will be easy to read and understand that we first do the interrupt subsystem mask, try enabling IR and x2apic and unmask the interrupt subsystem.

For io-apic this is not 100% symmetric. We mask io-apic, enable IR and if this succeeds we do not unmask io-apic.

Quoted 4 lines

Otherwise I am ok with this change.

thanks,
suresh

--
Gleb.

#5 lore raw
Quoted 5 lines · Gleb Natapov

I left interrupt masking in enable_IR_x2apic() because interrupt should be masked during transition to x2apic mode, so it can't be moved to enable_IR(). I moved io-apic into enable_IR() because the state of io-apic depend on whether IR was enabled or not, so I left it close to IR enabling logic.

This can be based on the outcome of enable_IR().

Quoted 3 lines

Also io-apic masking can fail, but we still want to
enable x2apic on KVM if possible, and moving io-apic masking to enable_IR_x2apic() will complicate the logic.

io-apic masking can fail because of memory allocation failures, right? If we want a simple solution, we can skip both x2apic and IR. This is not going to be common scenario anyhow. If we really hit this, we will worry about more things than x2apic :)

Quoted 7 lines
Quoted 5 lines

Can we keep it together so that it will be easy to read and understand that we first do the interrupt subsystem mask, try enabling IR and x2apic and unmask the interrupt subsystem.

For io-apic this is not 100% symmetric. We mask io-apic, enable IR and if this succeeds we do not unmask io-apic.

Correct. Can we do the same, otherwise we might have a situation (under kvm atleast) where io-apic will be active while we will be changing the cpu mode. Just trying to be defensive as these might lead to hard to debug corner case conditions.

thanks,
suresh