* 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. Thanks, Ingo -- 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
