Wu, Feng wrote on 2014-12-19: > > > Zhang, Yang Z wrote on 2014-12-19: >> Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' is >> set >> >> Wu, Feng wrote on 2014-12-19: >>> >>> >>> Zhang, Yang Z wrote on 2014-12-19: >>>> Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' >>>> is set >>>> >>>> Wu, Feng wrote on 2014-12-19: >>>>> >>>>> >>>>> iommu-boun...@lists.linux-foundation.org wrote on >>>> mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of: >>>>>> Cc: iommu@lists.linux-foundation.org; >>>>>> linux-ker...@vger.kernel.org; k...@vger.kernel.org >>>>>> Subject: RE: [v3 25/26] KVM: Suppress posted-interrupt when 'SN' >>>>>> is set >>>>>> >>>>>> Paolo Bonzini wrote on 2014-12-18: >>>>>>> >>>>>>> >>>>>>> On 18/12/2014 04:14, Wu, Feng wrote: >>>>>>>> >>>>>>>> >>>>>>>> linux-kernel-ow...@vger.kernel.org wrote on >>>>>> mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Paolo: >>>>>>>>> x...@kernel.org; Gleb Natapov; Paolo Bonzini; >>>>>>>>> dw...@infradead.org; >>>>>>>>> joro-zlv9swrftaidnm+yrof...@public.gmane.org; Alex Williamson; >>>>>>>>> joro-zLv9SwRftAIdnm+Jiang Liu Cc: >>>>>>>>> iommu@lists.linux-foundation.org; >>>>>>>>> linux-kernel-u79uwxl29ty76z2rm5m...@public.gmane.org; KVM list; >>>>>>>>> Eric Auger Subject: Re: [v3 25/26] KVM: Suppress >>>>>>>>> posted-interrupt when 'SN' is set >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/12/2014 16:14, Feng Wu wrote: >>>>>>>>>> Currently, we don't support urgent interrupt, all >>>>>>>>>> interrupts are recognized as non-urgent interrupt, so we >>>>>>>>>> cannot send posted-interrupt when 'SN' is set. >>>>>>>>> >>>>>>>>> Can this happen? If the vcpu is in guest mode, it cannot >>>>>>>>> have been scheduled out, and that's the only case when SN is set. >>>>>>>>> >>>>>>>>> Paolo >>>>>>>> >>>>>>>> Currently, the only place where SN is set is vCPU is >>>>>>>> preempted and >>>>>> >>>>>> If the vCPU is preempted, shouldn't the subsequent be ignored? >>>>>> What happens if a PI is occurs when vCPU is preempted? >>>>> >>>>> If a vCPU is preempted, the 'SN' bit is set, the subsequent >>>>> interrupts are suppressed for posting. >>>> >>>> I mean what happens if we don't set SN bit. From my point, if >>>> preempter already disabled the interrupt, it is ok to leave SN >>>> bit as zero. But if preempter enabled the interrupt, doesn't this >>>> mean he allow interrupt to happen? BTW, since there already has >>>> ON bit, so this means there only have one interrupt arrived at >>>> most and it doesn't hurt performance. Do we really need to set SN bit? >>> >>> >>> See this scenario: >>> vCPU0 is running on pCPU0 >>> --> vCPU0 is preempted by vCPU1 >>> --> Then vCPU1 is running on pCPU0 and vCPU0 is waiting for >>> --> schedule in runqueue >>> >>> If the we don't set SN for vCPU0, then all subsequent interrupts >>> for >>> vCPU0 is posted to vCPU1, this will consume hardware and software >> >> The PI vector for vCPU1 is notification vector, but the PI vector >> for >> vCPU0 should be wakeup vector. Why vCPU1 will consume this PI event? > > Wakeup vector is only used for blocking case, when vCPU is preempted > and waiting in the runqueue, the NV is the notification vector.
I see your point. But from performance point, if we can schedule the vCPU to another PCPU to handle the interrupt, it would helpful. But I remember current KVM will not schedule the vCPU in run queue (even though it got preempted) to another pCPU to run(Am I right?). So it may hard to do it. > > Thanks, > Feng > >> >>> efforts and in fact it is not needed at all. If SN is set for >>> vCPU0, VT-d hardware will not issue Notification Event for vCPU0 >>> when an interrupt is for it, but just setting the related PIR bit. >>> >>> Thanks, >>> Feng >>> >>>> >>>>> >>>>> Thanks, >>>>> Feng >>>>> >>>>>> >>>>>>>> waiting for the next scheduling in the runqueue. But I am not >>>>>>>> sure whether we need to set SN for other purpose in future. >>>>>>>> Adding SN checking here is just to follow the Spec. >>>>>>>> non-urgent interrupts are suppressed >>>>>>> when SN is set. >>>>>>> >>>>>>> I would change that to a WARN_ON_ONCE then. >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Yang >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> iommu mailing list >>>>>> iommu@lists.linux-foundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/iommu >>>> >>>> >>>> Best regards, >>>> Yang >>>> >> >> >> Best regards, >> Yang >> Best regards, Yang _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
