[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |