This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Losing PS/2 Interrupts
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Tue, 24 May 2011 12:04:23 +0100
Cc: Simon Graham <simon.graham@xxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Thomas Goetz <tcgoetz@xxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Tue, 24 May 2011 04:04:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DDB916F0200007800043155@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <3E2050B5-59DC-4E4F-9C8D-8C04A6B465EB@xxxxxxxxx> <F85CBA5B-F58C-416A-BF2C-ECE8BC62614F@xxxxxxxxx> <20110520175044.GA30367@xxxxxxxxxxxx> <5D477258-8216-48BD-8A93-186E044118B9@xxxxxxxxx> <4DDA366E0200007800042C71@xxxxxxxxxxxxxxxxxx> <1D3BFCDD-9D53-48BA-9ECD-D009AD535C2B@xxxxxxxxx> <alpine.DEB.2.00.1105231413020.12963@kaball-desktop> <04C6DFB0-08C8-4A8B-968F-FFE712BCABA1@xxxxxxxxx> <C8BA7030-8E00-4E8F-B82F-486966306818@xxxxxxxxx> <4DDB916F0200007800043155@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
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