| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 19 Dec 2014 05:25:44 +0000 From: "Zhang, Yang Z" <yang.z.zhang@...el.com> To: "Wu, Feng" <feng.wu@...el.com>, Paolo Bonzini <pbonzini@...hat.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org> CC: "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org> 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: >>> >>> >>> 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-bounces@...ts.linux-foundation.org wrote on >>>> mailto:iommu-bounces@...ts.linux-foundation.org] On Behalf Of: >>>>>> Cc: iommu@...ts.linux-foundation.org; >>>>>> linux-kernel@...r.kernel.org; kvm@...r.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-owner@...r.kernel.org wrote on >>>>>> mailto:linux-kernel-owner@...r.kernel.org] On Behalf Of Paolo: >>>>>>>>> x86@...nel.org; Gleb Natapov; Paolo Bonzini; >>>>>>>>> dwmw2@...radead.org; >>>>>>>>> joro-zLv9SwRftAIdnm+yROfE0A@...lic.gmane.org; Alex Williamson; >>>>>>>>> joro-zLv9SwRftAIdnm+Jiang Liu Cc: >>>>>>>>> iommu@...ts.linux-foundation.org; >>>>>>>>> linux-kernel-u79uwXL29TY76Z2rM5mHXA@...lic.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@...ts.linux-foundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/iommu >>>> >>>> >>>> Best regards, >>>> Yang >>>> >> >> >> Best regards, >> Yang >> Best regards, Yang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists