[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 18.01.17 at 05:57, <kevin.tian@xxxxxxxxx> wrote:
> Attached was my earlier comment:
> 
> --
>> >>> On 20.12.16 at 06:37, <kevin.tian@xxxxxxxxx> wrote:
>> >>  From: Xuquan (Quan Xu) [mailto:xuquan8@xxxxxxxxxx]
>> >> Sent: Friday, December 16, 2016 5:40 PM
>> >> -        if (pt_vector != -1)
>> >> -            vmx_set_eoi_exit_bitmap(v, pt_vector);
>> >> +        if ( pt_vector != -1 ) {
>> >> +            if ( intack.vector > pt_vector )
>> >> +                vmx_set_eoi_exit_bitmap(v, intack.vector);
>> >> +            else
>> >> +                vmx_set_eoi_exit_bitmap(v, pt_vector);
>> >> +        }
>> >
>> > Above can be simplified as one line change:
>> >    if ( pt_vector != -1 )
>> >            vmx_set_eoi_exit_bitmap(v, intack.vector);
>> 
>> Hmm, I don't understand. Did you mean to use max() here? Or
>> else how is this an equivalent of the originally proposed code?
>> 
> 
> Original code is not 100% correct. The purpose is to set EOI exit
> bitmap for any vector which may block injection of pt_vector - 
> give chance to recognize pt_vector in future intack and then do pt 
> intr post. The simplified code achieves this effect same as original
> code if intack.vector >= vector. I cannot come up a case why
> intack.vector might be smaller than vector. If this case happens,
> we still need enable exit bitmap for intack.vector instead of
> pt_vector for said purpose while original code did it wrong.
> 
> Thanks
> Kevin
> --
> 
> Using intack.vector is always expected here regardless of the 
> comparison result between intack.vector and pt_vector. The 
> reason why I was OK adding an ASSERT was simply to test 
> whether intack.vecor<pt_vector does happen which is
> orthogonal to the fix itself.

Well, a vector lower than pt_vector can't block delivery. Or wait:
Don't we need to consider vector classes here, i.e.

            ASSERT((intack.vector >> 4) >= (pt_vector >> 4));

?

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.