Re: [Qemu-devel] [PATCH v5 5/6] i8259: fix so that dropping IRQ level always clears the interrupt request

[Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>]

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