Re: [Xen-devel] Re: Losing PS/2 Interrupts

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 24 May 2011, Jan Beulich wrote:
> > Relevant code snippets included below:
> > 
> >         if (pirq_needs_eoi(irq)) {
> >                 printk(KERN_ERR "%s: irq %d handle_fasteoi_irq\n", 
> > __FUNCTION__, irq);
> >                 set_irq_chip_and_handler_name(irq, &xen_pirq_chip,
> >                                 handle_fasteoi_irq, name);
> >         } else {
> >                 printk(KERN_ERR "%s: irq %d handle_edge_irq\n", 
> > __FUNCTION__, irq);
> >                 set_irq_chip_and_handler_name(irq, &xen_pirq_chip,
> >                                 handle_edge_irq, name);
> >         }
> 
> Now this, imo, is a very good reason to not use handle_edge_irq()
> at all, and instead use the prior control flow (masking and clearing
> the event channel up front in do_upcall()) with only fasteoi (leaving
> aside per-CPU ones).
> 

Actually I think it is a good reason to fix pirq_needs_eoi that shouldn't
return unconditionally yes if dom0 doesn't support pirq_eoi_map.
The comment in Xen says:

    /*
     * Even edge-triggered or message-based IRQs can need masking from
     * time to time. If teh guest is not dynamically checking for this
     * via the new pirq_eoi_map mechanism, it must conservatively always
     * execute the EOI hypercall. In practice, this only really makes a
     * difference for maskable MSI sources, and if those are supported
     * then dom0 is probably modern anyway.
     */

Considering that I would rather avoid supporting pirq_eoi_map and we are
talking about edge triggered interrupts, do you think it would be safe
for me to send a patch to xen to change this behaviour?
Shouldn't we set XENIRQSTAT_needs_eoi only for level triggered
interrupts (and maybe maskable MSI sources)?

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