Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

["Xuquan (Quan Xu)" <xuquan8@xxxxxxxxxx>]

On January 16, 2017 1:26 PM, Tian, Kevin wrote:
>I cannot come up a valid reason for such situation (intack.vector is 0x30 while
>pt_vector is 0x38 from Chao's data). pt_update_irq is invoked before checking
>highest pending IRRs so pt_vector should be honored anyway.
>One possible reason is that being some reason pt_vector is not in vIRR at that
>point (due to some bug in the path from PIR to vIRR). 

btw, for PIR.. I find that there might be a bug in 
__vmx_deliver_posted_interrupt()...
why test_and_set_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu)) ??

static void __vmx_deliver_posted_interrupt(struct vcpu *v)
{
...
        if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu))
...
}

Suppose that vCPUx is in guest mode, there are two (even more) interrupts to 
vCPUx..
As the bit is set when delivers the first interrupt... the second interrupt is 
pending until next VM entry -- by PIR to vIRR..


Quan




However I didn't catch
>such bug simply by looking at code. We need reproduce this problem in
>developer side to find out actual reason. Andrew it'd be helpful if you can 
>help
>Quan/Chao to find out more test environment info.
>
>One thing noted though. The original patch from Quan is actually orthogonal to
>this ASSERT. Regardless of whether intack.vector is larger or smaller than
>pt_vector, we always require the trick as long as pt_vector is not the one 
>being
>currently programmed to RVI. Then do we want to revert the whole commit
>until the problem is finally fixed, or OK to just remove ASSERT (or replace 
>with
>WARN_ON with more debug info) to unblock test system before the fix is
>ready?
>
>Thanks
>Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel