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

[Chao Gao <chao.gao@xxxxxxxxx>]

On Wed, Mar 29, 2017 at 03:28:43AM +0000, Xuquan (Quan Xu) wrote:
>On March 22, 2017 2:14 PM, Chao Gao wrote:
>>On Wed, Mar 22, 2017 at 06:47:33AM -0600, Jan Beulich wrote:
>>>> 3. We read RTE 3 times. 1st happens when we set vIRR. 2nd happens
>>>> when
>>>> pt_update_irq() returns. 3rd happens in pt_intr_post(). If guest
>>>> changes the vector in RTE during the window, it will also incur
>>>> losing or getting more periodic timer interrupt.
>>>
>>>Which raises the question whether latching the value read the first
>>>time would address the issue you demonstrate with the test case.
>>>Or alternatively deferring writes to take effect only once readers are
>>>done with their perhaps multiple accesses?
>>
>>I think your solution is better.
>>
>>>
>>>Can you get in touch with your chipset folks to find out whether
>>>hardware has cases where multiple reads occur during the processing of
>>>a single event?
>>
>>Yes, I will come back once I get how they handle similar processes.
>>
>>>
>
>Chao,
>Based on Jan's suggestion, a rcu lock may be helpful to you..
>Specifically, you can refer to rcu_read_lock() in kvm code..

Thanks for your advice. I will read this.

>
>btw, I still can't get how this caused the assertion clearly.. could you 
>describe it in short? :)

In short, it caused by reading IOAPIC RTE twice. The first time is for setting 
a bit in vIRR.
The second one is to return the bit we set for setting EOI later. But the 
vector in RTE can be changed
by guest during the time window. If the new vector is bigger than the old one 
(such as 0x38 > 0x30),
the assertion may fail.

>
>
>
>Quan

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