On Mon, Nov 19, 2012 at 04:28:31PM +0100, BALATON Zoltan wrote: > On Sun, 9 Sep 2012, Matthew Ogilvie wrote: > > Intel's definition of "edge triggered" means: "asserted with a > > low-to-high transition at the time an interrupt is registered and > > then kept high until the interrupt is served via one of the > > EOI mechanisms or goes away unhandled." > > > > So the only difference between edge triggered and level triggered > > is in the leading edge, with no difference in the trailing edge. > > What happened to this patch? Any chance it will be in 1.3? > > Thanks, > BALATON Zoltan
I kind of doubt it will make it into 1.3, although I would like to get it in eventually. Maybe the first few essentially unrelated trivial patches can make it in? Yours is the first comment I've seen since I've posted version 6 of the series (this particular patch is the same as version 5). The lack of feedback combined with other demands on my time have prevented me from progressing on this for over a month and a half. Status: * We can't completely fix the i8259 model without addressing some issues in the i8254 model as well. The i8254 issues (very short duty cycle on IRQ0 causing lost timer ticks) become rather severe if you try to fix the i8259 without fixing the i8254. * But the obvious direct fixes to the i8254 may risk causing issues with breaking migration between pre-fix and post-fix versions of qemu, due to lost and/or extra timer interrupts. I'm not sure how big of an issue this is in practice, but it is a concern. * I've outlined some possible ways to address the migration issue in the cover letter of version 6 of the patch series. * Similar issue cascades exist in the in-kernel KVM model as well. The i8254 issues are even more severe in KVM: timer interrupts are always lost [0-length duty cycle in KVM model], instead of sometimes lost [non-0 but tiny duty cycle in qemu model]. * I'm not aware of any similar problems in other device interrupt models, but I haven't really checked them, either. Next step?: In the absense of any other suggestions, I'm thinking about rolling a version of the series that leaves IRQ0 (timer) working the way it does in qemu 1.2. Except in the i8254 I'll immediately preceed each "intended to be leading edge transition" with an explicit lowering of IRQ0, so that if migrating from some future really-fixed version that leaves IRQ0 high most of the time, it will still recognize the new edge. A "real" fix would then be delayed (years?) until versions without this first stage fix are no longer in production. I can probably get this done this weekend. [Although I'm not sure how to deal with the issue that some of the i8254 modes' leading edge transitions are off by one count. Perhaps we'll need multiple intermediate stages, or one of the other strategies outlined in the version 6 cover letter.] Or does anyone have a better suggestion? - Matthew Ogilvie