[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/4] VMX: Add posted interrupt supporting
On 09/04/2013 09:23, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote: > Keir Fraser wrote on 2013-04-09: >> On 09/04/2013 08:58, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> 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 > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |