On Mon, Dec 17, 2012 at 01:30:49PM +0800, Yang Zhang wrote: > From: Yang Zhang <yang.z.zhang@xxxxxxxxx> > > Virtual interrupt delivery avoids KVM to inject vAPIC interrupts > manually, which is fully taken care of by the hardware. This needs > some special awareness into existing interrupr injection path: > > - for pending interrupt, instead of direct injection, we may need > update architecture specific indicators before resuming to guest. > > - A pending interrupt, which is masked by ISR, should be also > considered in above update action, since hardware will decide > when to inject it at right time. Current has_interrupt and > get_interrupt only returns a valid vector from injection p.o.v. > > Signed-off-by: Kevin Tian <kevin.tian@xxxxxxxxx> > Signed-off-by: Yang Zhang <yang.z.zhang@xxxxxxxxx> Resuming previous discussion: > > How about to recaculate irr_pending according the VIRR on each > > vmexit? > > > No need really. Since HW can only clear VIRR the only situation that > may > happen is that irr_pending will be true but VIRR is empty and > apic_find_highest_irr() will return correct result in this case. Self-IPI does cause VIRR to be set, see "29.1.5 Self-IPI Virtualization". Also, an example of problem with ISR caching optimization (which was written with ISR/IRR management entirely in software): isr_count variable is never incremented (because HW sets ISR): kvm_cpu_get_interrupt does not call into kvm_get_apic_interrupt if virtual interrupt delivery enabled. Therefore apic_find_highest_isr can return -1 even though VISR is not zero. In that case (VISR non-zero but apic_find_highest_isr() == -1), apic_update_ppr does not correctly set PPR = max(ISRV, TPR) Which can result in kvm_arch_vcpu_runnable returning 1 when it should not. Please disable usage of isr_count if virtual interrupt delivery enabled. Given that self-IPI writes to VIRR, also please disable usage of highest_isr_cache and irr_pending. -- 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
