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

Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue



>>> On 23.12.16 at 13:24, <xuquan8@xxxxxxxxxx> wrote:
> On December 22, 2016 4:12 PM, Jan Beulich wrote:
>>>>> On 21.12.16 at 06:44, <xuquan8@xxxxxxxxxx> wrote:
>>> --- a/xen/arch/x86/hvm/vmx/intr.c
>>> +++ b/xen/arch/x86/hvm/vmx/intr.c
>>> @@ -315,9 +315,13 @@ void vmx_intr_assist(void)
>>>          * Set eoi_exit_bitmap for periodic timer interrup to cause
>>EOI-induced VM
>>>          * exit, then pending periodic time interrups have the chance
>>to be injected
>>>          * for compensation
>>> +        * Set eoi_exit_bitmap for intack.vector when it's higher than
>>pending
>>> +        * periodic time interrupts. This way we can guarantee there's
>>always a chance
>>> +        * to post periodic time interrupts when periodic time
>>interrupts becomes the
>>> +        * highest one
>>>          */
>>>          if (pt_vector != -1)
>>> -            vmx_set_eoi_exit_bitmap(v, pt_vector);
>>> +            vmx_set_eoi_exit_bitmap(v, intack.vector);
>>
>>The comment does not clarify why max(pt_vector, intack.vector) is not
>>needed. And I'd expect you to add ASSERT(intack.vector >= pt_vector) then,
>>to prove this (and one might argue that this addition could be sufficient
>>documentation, albeit perhaps a brief comment next to the assertion
>>would help readers of this non-trivial piece of code).
>>
> Kevin or Jan..
> ASSERT(...) is ok to me.. Could you help me give a brief comment? 

I don't see why you couldn't simply use what Kevin said in reply
to my earlier question regarding the lack of max() here.

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®.