RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination

[Tian, Kevin]

> From: Wu, Feng
> Sent: Thursday, January 21, 2016 12:43 PM
> 
> > -----Original Message-----
> > From: kvm-owner@xxxxxxxxxxxxxxx [mailto:kvm-owner@xxxxxxxxxxxxxxx] On
> > Behalf Of Yang Zhang
> > Sent: Thursday, January 21, 2016 11:35 AM
> > To: Wu, Feng <feng.wu@xxxxxxxxx>; pbonzini@xxxxxxxxxx;
> > rkrcmar@xxxxxxxxxx
> > Cc: linux-kernel@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx
> > Subject: Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the
> > interrupt is not single-destination
> >
> > On 2016/1/21 11:14, Wu, Feng wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Yang Zhang [mailto:yang.zhang.wz@xxxxxxxxx]
> > >> Sent: Thursday, January 21, 2016 11:06 AM
> > >> To: Wu, Feng <feng.wu@xxxxxxxxx>; pbonzini@xxxxxxxxxx;
> > >> rkrcmar@xxxxxxxxxx
> > >> Cc: linux-kernel@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx
> > >> Subject: Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the
> > >> interrupt is not single-destination
> > >>
> > >> On 2016/1/20 9:42, Feng Wu wrote:
> > >>> When the interrupt is not single destination any more, we need
> > >>> to change back IRTE to remapped mode explicitly.
> > >>>
> > >>> Signed-off-by: Feng Wu <feng.wu@xxxxxxxxx>
> > >>> ---
> > >>>    arch/x86/kvm/vmx.c | 11 ++++++++++-
> > >>>    1 file changed, 10 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > >>> index e2951b6..13d14d4 100644
> > >>> --- a/arch/x86/kvm/vmx.c
> > >>> +++ b/arch/x86/kvm/vmx.c
> > >>> @@ -10764,8 +10764,17 @@ static int vmx_update_pi_irte(struct kvm
> > >> *kvm, unsigned int host_irq,
> > >>>    		 */
> > >>>
> > >>>    		kvm_set_msi_irq(e, &irq);
> > >>> -		if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu))
> > >>> +		if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu)) {
> > >>> +			/*
> > >>> +			 * Make sure the IRTE is in remapped mode if
> > >>> +			 * we don't handle it in posted mode.
> > >>> +			 */
> > >>> +			pi_set_sn(vcpu_to_pi_desc(vcpu));
> > >>> +			ret = irq_set_vcpu_affinity(host_irq, NULL);
> > >>> +			pi_clear_sn(vcpu_to_pi_desc(vcpu));
> > >>> +
> > >>>    			continue;
> > >>> +		}
> > >>>
> > >>>    		vcpu_info.pi_desc_addr = __pa(vcpu_to_pi_desc(vcpu));
> > >>>    		vcpu_info.vector = irq.vector;
> > >>>
> > >>
> > >> I am still feel weird with this change: according the semantic of VT-d
> > >> posted interrupt, the interrupt will injected to guest through posted
> > >> notification and /proc/interrupts shows the same meaning. But now,
> > >> without being aware of user, the interrupt changes to legacy way and it
> > >> appears on different entry on /proc/interrupts. It looks weird.
> > >
> > > I don't think it has problem here, IMO, this is exactly how it works.
> > > There should be different entry for the interrupts in VT-d PI mode
> > > and leagcy mode.
> >
> > I am not saying any problem here. Just feel weird. From a normal user's
> > point, he has turned on the VT-d pi and according the semantic of VT-d
> > pi, he should not observe the interrupt through legacy mode, but now he
> > do see it. Maybe print out a message here will be helpful, like what you
> > did for disabled lapic found during irq injection.
> 
> Even VT-d PI is on, not all interrupts can be handled by it, the reason the
> interrupts is changed back to legacy mode is because the user changes
> the affinity, and it cannot be handle in PI mode, and hence legacy mode
> is used. It is the user's behavior that cause this mode change, seems it is
> not so weird to me. But add some message here is good idea, just like
> what I did later in this function, I can also add the following trace
> message here.
> 
>                 trace_kvm_pi_irte_update(vcpu->vcpu_id, host_irq, e->gsi,
>                                 vcpu_info.vector, vcpu_info.pi_desc_addr, set);
> 
> Thanks,
> Feng
> 

Right. Whether the interrupt is delivered into guest directly with PI or with 
legacy mode, is completely agnostic to the guest. Guest can't tell
or set any expectation on the underlying delivering method, so there is no
guest visible impact. 

Thanks
Kevin