Re: [Xen-devel] newer Linux: handle_level_irq() vs. handle_fasteoi_irq()

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Apr 22, 2010 at 01:09:08PM +0100, Jan Beulich wrote:
> In order to be able to properly disable level triggered interrupts that,
> due to malfunctioning hardware/firmware, never get de-asserted,
> the use of handle_level_irq() in both pv-ops Dom0 and forward
> ported kernels (starting with 2.6.19) seems problematic: Other than
> with 2.6.18's use of __do_IRQ(), irq_chip->end() doesn't get called
> anymore, and there also is no replacement call made from that
> function (->umask() is only being called on non-disabled IRQs), and
> hence the respective logic contained in pirq_end() doesn't really get
> used anymore. handle_fasteoi_irq(), otoh, has an unconditional
> ->eoi() callout at its end, which would suit these needs.

In the PV-OPS kernel, there are no calls to manipulate the LAPIC or
IO/APIC anymore. The ACK is replaced with a PHYSDEVOP_eoi hypercall.

The unmasking/masking is done on the event channel. All of the logic
related to handling either the edge or level (or fasteoi level) is done
in the hypervisor.
> 
> The main difference of handle_fasteoi_irq() compared with
> handle_level_irq() is that the IRQ doesn't get masked upfront.
> I'm not really that much into the necessary details here, but it
> would seem that using handle_fasteoi_irq() should be possible
> if a hypothetical pirq_eoi() called clear_evtchn() along with
> what end_pirq() currently does.
> 
> Any insight on potential problems with this would be
> appreciated.

<scratches his head>  I don't know about the XenLinux forward ported
patches but I think in the PV-OPS realm we don't have to worry about it.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel