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 <[email protected]>
> >
> > 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
