Ingo Molnar wrote on 2013-03-08: > > * Gleb Natapov <gleb@xxxxxxxxxx> wrote: > >> On Fri, Mar 08, 2013 at 03:05:45PM +0100, Ingo Molnar wrote: >>> >>> * Gleb Natapov <gleb@xxxxxxxxxx> wrote: >>> >>>> On Fri, Mar 08, 2013 at 02:26:25PM +0100, Ingo Molnar wrote: >>>>> >>>>> * Yang Zhang <yang.z.zhang@xxxxxxxxx> wrote: >>>>> >>>>>> diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c >>>>>> index 6e03b0d..2329a54 100644 >>>>>> --- a/arch/x86/kernel/irqinit.c >>>>>> +++ b/arch/x86/kernel/irqinit.c >>>>>> @@ -205,6 +205,10 @@ static void __init apic_intr_init(void) >>>>>> >>>>>> /* IPI for X86 platform specific use */ >>>>>> alloc_intr_gate(X86_PLATFORM_IPI_VECTOR, x86_platform_ipi); >>>>>> +#ifdef CONFIG_HAVE_KVM >>>>>> + /* IPI for KVM to deliver posted interrupt */ >>>>>> + alloc_intr_gate(POSTED_INTR_VECTOR, kvm_posted_intr_ipi); >>>>>> +#endif >>>>> >>>>> Please avoid wasting an IDT entry by reusing x86_platform_ipi. >>>>> >>>>> A KVM guest is in essence one type of 'x86 platform', and this >>>>> callback is used by hardware platforms, so collision is not an issue >>>>> AFAICS. >>>> >>>> This is IPI send by a host though. >>> >>> But received on the guest side, right? >> >> Not directly. If CPU that receives it happens to run in a guest mode it >> makes VMX to re-evaluate pending interrupt and inject one if possible >> without vmexit. If CPU is not in a guest mode the handler for the IPI >> is called in a host mode and does nothing. Guest code is unaware of the >> existence of that IPI. > > Ok, I guess a separate IPI is fine (and better) in this case then. Is it ok to add your name in 'ack by' list? Best regards, Yang -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
