Sorry for the late response > -----Original Message----- > From: Avi Kivity [mailto:avi@xxxxxxxxxx] > Sent: Friday, September 07, 2012 12:30 AM > To: Li, Jiongxi > Cc: kvm@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 3/5]KVM:x86, apicv: enable virtual interrupt delivery for > VMX > > On 09/05/2012 08:41 AM, Li, Jiongxi wrote: > > - before returning to guest, RVI should be updated if any pending IRRs > > process pending interrupts does that for you, so you only need this with > KVM_SET_APIC. > > > - EOI exit bitmap controls whether an EOI write should cause VM-Exit. > > if set, a trap-like induced EOI VM-Exit is triggered. Keep all the > > bitmaps cleared for now, which should be enough to allow a MSI based > > device passthrough > > What about level-triggered interrupts, or interrupts which have ack notifiers > set? > We will merge the EOI exit bitmap part patch > > > > -static void apic_send_ipi(struct kvm_lapic *apic) > > +/* > > + * this interface assumes a trap-like exit, which has already > > +finished > > + * desired side effect including vISR and vPPR update. > > + */ > > +void kvm_apic_set_eoi(struct kvm_vcpu *vcpu, int vector) { > > + struct kvm_lapic *apic = vcpu->arch.apic; > > + int trigger_mode; > > + > > + if (apic_test_and_clear_vector(vector, apic->regs + APIC_TMR)) > > + trigger_mode = IOAPIC_LEVEL_TRIG; > > + else > > + trigger_mode = IOAPIC_EDGE_TRIG; > > + > > + if (!(apic_get_reg(apic, APIC_SPIV) & APIC_SPIV_DIRECTED_EOI)) > > + kvm_ioapic_update_eoi(apic->vcpu->kvm, vector, trigger_mode); > > + kvm_make_request(KVM_REQ_EVENT, apic->vcpu); } > > +EXPORT_SYMBOL_GPL(kvm_apic_set_eoi); > > What's the difference between this and apic_set_eoi()? In kvm_apic_set_eoi, We can use the vector directly from exit_qualification while there is EOI-induced VMExit, and doesn't need to do the 'clear isr', 'update ppr' things which are handled by hardware. > > > + > > + static void apic_send_ipi(struct kvm_lapic *apic) > > Extra space added. OK. > > > /* > > * If nested=1, nested virtualization is supported, i.e., guests may use > > * VMX and be a hypervisor for its own guests. If nested=0, guests > > may not @@ -430,6 +433,8 @@ struct vcpu_vmx { > > > > bool rdtscp_enabled; > > > > + u64 eoi_exit_bitmap[4]; > > + > > Unused? This is used in PATCH 4/5 > > > > > @@ -3876,6 +3894,15 @@ static int vmx_vcpu_setup(struct vcpu_vmx > *vmx) > > vmx_secondary_exec_control(vmx)); > > } > > > > + if (enable_apicv_vid) { > > + vmcs_write64(EOI_EXIT_BITMAP0, 0); > > + vmcs_write64(EOI_EXIT_BITMAP1, 0); > > + vmcs_write64(EOI_EXIT_BITMAP2, 0); > > + vmcs_write64(EOI_EXIT_BITMAP3, 0); > > + > > + vmcs_write16(GUEST_INTR_STATUS, 0); > > Need to update GUEST_INTR_STATUS after live migration (or perhaps also > when enabling the APIC?) After live migration, GUEST_INTR_STATUS will be updated in VMEntry. 'kvm_x86_ops->update_irq(vcpu)' function does that. > > > > -- > error compiling committee.c: too many arguments to function -- 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
