[Top][All Lists]

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

Re: [PATCH]: gnumach - simplify interrupt handling

From: Samuel Thibault
Subject: Re: [PATCH]: gnumach - simplify interrupt handling
Date: Mon, 11 Nov 2019 18:57:25 +0100
User-agent: NeoMutt/20170609 (1.8.3)

Samuel Thibault, le lun. 11 nov. 2019 17:52:36 +0100, a ecrit:
> That being said, now netdde with e1000 works only because linux_intr
> calls disable_irq before queue_intr. If that is not done, we keep
> getting interrupts. This really looks like an edge-vs-level trigger
> issue which we need to clear out. Possibly it's indeed the hardware
> which keeps the interrupt getting triggered until the driver manages it,
> and there is nothing around that.

I had a look inside qemu, it's the ELCR which forces level-triggered
interrupts here. This seems to be set by the PCI BIOS, apparently
because that's what PCI does anyway. So yes, apparently we're screwed,
we have to get the userland driver to tell when it has acked the
hardware before being able to enable the interrupt again.

So we do need that device_intr_enable RPC. The interface and/or
implementation should however probably be fixed into supporting
several drivers using the same IRQ, to notify each of them and
*waiting* for both of them to "re-enable" the irq before enabling
it for real. I.e. probably deliver_intr should not only send a
notification but also expect its acknowledgment, thus a routine instead
of simpleroutine.

A simpler way for now would be to make deliver_intr and
device_intr_enable count how many "disables" we have for each irq.
Both device_intr_register and deliver_intr would increase it (and thus
disable the irq), and userland would have to call device_intr_enable
to decrease the counter so the irq can be re-enabled. Of course if
some userland "forgets" to call device_intr_enable(), the irq will
stay disabled and we're screwed with anything else sharing the irq
until userland gets killed for instance.  But at least it seems like a
workable way for sharing interrupts between different userland processes
(and gnumach drivers if any, e.g. the current ahci).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]