Gleb Natapov wrote on 2013-03-18: > 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"? Just ignore it. I will send out the fixing with APICv patch. 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
