From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 3/4] VMX: Add posted interrupt supporting Date: Tue, 09 Apr 2013 09:40:15 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Zhang, Yang Z" , "xen-devel@lists.xen.org" Cc: "Zhang, Xiantao" , "JBeulich@suse.com" List-Id: xen-devel@lists.xenproject.org On 09/04/2013 09:23, "Zhang, Yang Z" wrote: > Keir Fraser wrote on 2013-04-09: >> On 09/04/2013 08:58, "Zhang, Yang Z" wrote: >> >>> If posted interrupt arrived after vmx_intr_assit() and before vmentry, then >>> the interrupt cannot be inject to guest in time. >> >> But pending virtual interrupts are picked up during vmentry aren't they? > Yes. But in this case, the interrupt still in PIR not in vIRR, and vmentry > cannot pick up interrupt from PIR. So we must sync PIR to vIRR before vmentry. Ah, I see. That makes sense. I think I would like more code sharing of vcpu_kick(), but I know how to make that change myself easier than explaining it. So I'm happy for this part of the patch to go in as-is, and I'd clean up after. -- Keir >> So if the IPI occurs before vmentry, why is there a race? Isn't the only >> purpose of __vmx_deliver_posted_interrupt() to ensure that the pending >> virtual interrupts of the given vcpu get scanned/handled by the >> appropriate processor? >> >> -- Keir >> >>> vmx_asm_do_vmentry: >>> call vmx_intr_assist >>> call nvmx_switch_guest >>> ASSERT_NOT_IN_ATOMIC >>> <---------if posted interrupt arrived here and >>> we don't set softirq, then the interrupt will be delay until next vmentry. >>> GET_CURRENT(%rbx) >>> cli >>> >>> mov VCPU_processor(%rbx),%eax >>> shl $IRQSTAT_shift,%eax >>> lea irq_stat+IRQSTAT_softirq_pending(%rip),%rdx >>> cmpl $0,(%rdx,%rax,1) >>> jnz .Lvmx_process_softirqs >>> Actually, the posted interrupt is same with a normal vcpu kick IPI, except >>> that if cpu received it in non-root mode, it will not cause vmext. So we >>> must >>> follow the vcpu_kick logic. >> > > > Best regards, > Yang > >