> -----Original Message----- > From: Paolo Bonzini [mailto:paolo.bonzini@xxxxxxxxx] On Behalf Of Paolo > Bonzini > Sent: Friday, October 16, 2015 2:13 AM > To: David Matlack <dmatlack@xxxxxxxxxx>; Wu, Feng <feng.wu@xxxxxxxxx> > Cc: alex.williamson@xxxxxxxxxx; Joerg Roedel <joro@xxxxxxxxxx>; Marcelo > Tosatti <mtosatti@xxxxxxxxxx>; eric.auger@xxxxxxxxxx; kvm list > <kvm@xxxxxxxxxxxxxxx>; iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v9 17/18] KVM: Update Posted-Interrupts Descriptor when > vCPU is blocked > > > > On 15/10/2015 19:39, David Matlack wrote: > > But after spending more time reading the source code this morning I > > found that kvm_vcpu_check_block() eventually calls into > > vmx_sync_pir_to_irr(), which copies PIR to IRR and clears ON. And then > > apic_find_highest_irr() detects the pending posted interrupt. > > Right. And related to this, Feng, can you check if this is still > necessary on kvm/queue: > > @@ -6518,6 +6523,20 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) > kvm_vcpu_reload_apic_access_page(vcpu); > } > > + /* > + * KVM_REQ_EVENT is not set when posted interrupts are set by > + * VT-d hardware, so we have to update RVI unconditionally. > + */ > + if (kvm_lapic_enabled(vcpu)) { > + /* > + * Update architecture specific hints for APIC > + * virtual interrupt delivery. > + */ > + if (kvm_x86_ops->hwapic_irr_update) > + kvm_x86_ops->hwapic_irr_update(vcpu, > + kvm_lapic_find_highest_irr(vcpu)); > + } > + > if (kvm_check_request(KVM_REQ_EVENT, vcpu) || req_int_win) { > kvm_apic_accept_events(vcpu); > if (vcpu->arch.mp_state == KVM_MP_STATE_INIT_RECEIVED) { > @@ -6534,13 +6553,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) > kvm_x86_ops->enable_irq_window(vcpu); > > if (kvm_lapic_enabled(vcpu)) { > - /* > - * Update architecture specific hints for APIC > - * virtual interrupt delivery. > - */ > - if (kvm_x86_ops->hwapic_irr_update) > - kvm_x86_ops->hwapic_irr_update(vcpu, > - kvm_lapic_find_highest_irr(vcpu)); > update_cr8_intercept(vcpu); > kvm_lapic_sync_to_vapic(vcpu); > } > I think the above code is needed, before the place where 'KVM_REQ_EVENT' got checked in vcpu_enter_guest(), VT-d hardware can issue notification event at any time. Consider the following scenario: vcpu_run() { ...... for(;;) { point #1 vcpu_enter_guest() } point #2 } For example, if we receive notification events issued by VT-d hardware at point #1 and point#2, then enter vcpu_enter_guest() with 'KVM_REQ_EVENT' not set, the interrupts cannot be delivered to guest during _this_ VM-Entry. The point is that VT-d hardware can issue notification event at any time, but it cannot set 'KVM_REQ_EVENT' like software does. Maybe one thing we can do is only executing the following code when vt-d pi is enabled, + /* + * KVM_REQ_EVENT is not set when posted interrupts are set by + * VT-d hardware, so we have to update RVI unconditionally. + */ + if (kvm_lapic_enabled(vcpu)) { + /* + * Update architecture specific hints for APIC + * virtual interrupt delivery. + */ + if (kvm_x86_ops->hwapic_irr_update) + kvm_x86_ops->hwapic_irr_update(vcpu, + kvm_lapic_find_highest_irr(vcpu)); + } + And do this inside the KVM_REQ_EVENT check when VT-d PI is not enabled. Thanks, Feng > > It may be obsolete now that we have the patch from Radim to set > KVM_REQ_EVENT > in vmx_sync_pir_to_irr > (http://permalink.gmane.org/gmane.linux.kernel/2057138). > > Thanks, > > Paolo ��.n��������+%������w��{.n�����o�^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
