On Mon, Mar 18, 2013 at 02:49:25AM +0000, Zhang, Yang Z wrote: > Zhang, Yang Z wrote on 2013-03-15: > > From: Yang Zhang <yang.z.zhang@xxxxxxxxx> > > > > The follwoing patches are adding the Posted Interrupt supporting to KVM: > > The first patch enables the feature 'acknowledge interrupt on vmexit'.Since > > it is required by Posted interrupt, we need to enable it firstly. > > > > And the subsequent patches are adding the posted interrupt supporting: > > Posted Interrupt allows APIC interrupts to inject into guest directly > > without any vmexit. > > > > - When delivering a interrupt to guest, if target vcpu is running, > > update Posted-interrupt requests bitmap and send a notification event > > to the vcpu. Then the vcpu will handle this interrupt automatically, > > without any software involvemnt. > > - If target vcpu is not running or there already a notification event > > pending in the vcpu, do nothing. The interrupt will be handled by > > next vm entry > > NOTE: We don't turn on the Posted Interrupt until the coalesced issue is > > solved. > > > > Changes from v5 to v6: > > * Split sync_pir_to_irr into two functions one to query whether PIR is empty > > and the other to perform the sync. > > * Add comments to explain how vmx_sync_pir_to_irr() work. > > * Rebase on top of KVM upstream. > > > > Changes from v4 to v5: > > * Add per cpu count for posted IPI handler. > > * Dont' check irr when delivering interrupt. Since we can not get interrupt > > coalesced info with Posted Interrupt. So there is no need to check the > > irr. There is another patch will changed current interrupt coalesced > > logic. Before it, we will not turn on Posted Interrupt. * Clear > > outstanding notification bit after call local_irq_disable, but before > > check request. As Marcelo suggested, we can ensure the IPI not lost in > > this way * Remove the spinlock. Same as item 2, if not need to get > > coalesced info, then no need the lock. > > * Rebase on top of KVM upstream. > > > > Yang Zhang (5): > > KVM: VMX: Enable acknowledge interupt on vmexit > > KVM: VMX: Register a new IPI for posted interrupt > > KVM: VMX: Check the posted interrupt capability > > KVM: VMX: Add the algorithm of deliver posted interrupt > > KVM : VMX: Use posted interrupt to deliver virtual interrupt > > arch/x86/include/asm/entry_arch.h | 4 + > > arch/x86/include/asm/hardirq.h | 3 + > > arch/x86/include/asm/hw_irq.h | 1 + > > arch/x86/include/asm/irq_vectors.h | 5 + > > arch/x86/include/asm/kvm_host.h | 5 + arch/x86/include/asm/vmx.h > > | 4 + arch/x86/kernel/entry_64.S | 5 + > > arch/x86/kernel/irq.c | 22 ++++ > > arch/x86/kernel/irqinit.c | 4 + arch/x86/kvm/irq.c > > | 3 +- arch/x86/kvm/lapic.c | 29 ++++- > > arch/x86/kvm/lapic.h | 2 + arch/x86/kvm/svm.c > > | 30 +++++ arch/x86/kvm/vmx.c | 223 > > ++++++++++++++++++++++++++++++++---- arch/x86/kvm/x86.c > > | 8 +- virt/kvm/kvm_main.c | 1 + 16 files changed, > > 320 insertions(+), 29 deletions(-) > Are there any other comments with this patch? > Haven't reviewed it yet, will do ASAP. "Use eoi to track RTC interrupt delivery status" series is pre-request for this one. > For TMR issue, since it has nothing to do with APICv, if we really need to handle it later, then we may need a separate patch to fix it. But currently, we may focused on APICv only. > What do you mean by "TMR has nothing to do with APICv"? -- Gleb. -- 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
