Re: [Qemu-devel] [PATCH v4 5/5] i8259: fix dynamically masking slave IRQs with IMR register

[Maciej W. Rozycki]

On Tue, 4 Sep 2012, Jan Kiszka wrote:

> >> What I'm trying to understand and translate from the description is
> >> rather "note that for inputs a high-to-low transition cancels the
> >> interrupt as in the level-triggered mode." This is surely not what we do
> >> right now. OTOH, I'm afraid that switching to this mode in the PIC can
> >> cause problems elsewhere, with devices that actually inject short
> >> low-high-low signals. Still wrapping my head around it...
> > 
> >  That won't work reliably with true 8259A hardware -- for an 
> 
> Ok, then we have to scan our code base for such device models that won't
> survive with real 8259A hardware. That can only be devices attached to
> edge-only inputs of the PIC, namely the PIT, the keyboard controller,
> the RTC and FPU emulation. They basically need to generate high-low-high
> transitions on new events, instead of low-high-low (via qemu_irq_pulse
> e.g.). I'm I on the right track?

 They shouldn't be the problem unless we've got an implementation problem:

 * The 8254 PIT is normally configured in mode 2 or 3 in the PC/AT 
   architecture.  In the former its output is high (active) all the time 
   except from one (last) clock cycle.  In the latter a wave that has a 
   duty cycle close or equal to 0.5 (depending on whether the divider is 
   odd or even) is produced, so no short pulses either.  I don't remember 
   the other four modes -- have a look at the datasheet if interested, but 
   I reckon they're not really compatible with the wiring anyway, e.g. the 
   gate is hardwired enabled.

 * The 8042 keyboard controller requires an interrupt acknowledge (by 
   reading its data port, normally at the address 0x60 in the PC/AT port 
   I/O space) to clear its output, so no concern here either (this is BTW 
   how many years ago I actually learnt the hard way how the 
   edge-triggered mode works in the 8259A -- reading the KBC's data port 
   in the main program a tight loop with the keyboard interrupt enabled 
   will lead to a spurious interrupt each time data is supplied).  I 
   believe it's otherwise edge-triggered though (I don't have an 8042 
   datasheet handy, I would have to dig for a hardcopy that I left 
   abroad).

 * The MC146818 RTC interrupt is level triggered and has to be 
   acknowledged by reading Register C.

 * The i287/i387 FPU interrupt (in the PC/AT compatibility mode) is 
   latched and requires the location at the address 0xf0 in the PC/AT port 
   I/O space to be poked at to acknowledge.  It can therefore be 
   considered level-triggered (overall the design is busted and you have 
   to be very careful not to freeze the system when handling the FPU error 
   this way rather than via the FPU exception).

 Did I miss anything?

  Maciej