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

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



On 24/03/2017 08:17, Jan Beulich wrote:
>>>> On 24.03.17 at 08:48, <kevin.tian@xxxxxxxxx> wrote:
>>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>>> Sent: Wednesday, March 22, 2017 8:48 PM
>>>
>>>> 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?
>>>
>>> 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?
>> There is a similar case. For level-triggered interrupt, there is a "remote 
>> IRR"
>> bit in RTE which is set to 1 when LAPIC accepts the level interrupt sent by 
>> IOAPIC.  It's then cleared by EOI broadcast from LAPIC later, based on 
>> matching interrupt vectors. If software happens to change the vector of 
>> the said RTE in-between, "remote IRR" bit will never be cleared (it 
>> expects an EOI with new vector now while actual EOI for previous injection
>> contains old vector).
> Hmm, I'd expect such a write to clear IRR at once, if somebody
> really wrote code this way. Or is the bit wrongly documented R/W?

The IRR is read only.  This behaviour is the root cause of one of the
earliest bugs I fixed in the hypervisor, c/s 12b6ea528f

(And on re-reading the commit message, I still haven't found time to
full-fill "This fix is distinctly a temporary hack, waiting on a cleanup
of the irq code.")

~Andrew

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