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 14:52:24 +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 06:50:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DDBBF98020000780004328A@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> <alpine.DEB.2.00.1105241157450.12963@kaball-desktop> <4DDBBF98020000780004328A@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Tue, 24 May 2011, Jan Beulich wrote:
> > 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)?
> Only if you can prove that the very first part of that comment is
> incorrect (in including "edge-triggered" and ignoring whether MSI
> sources are maskable). And your Linux side code would then still
> be incorrect for maskable MSIs (you'd continue to handle them
> as fasteoi with no up front clearing/masking while that is necessary
> as Thomas' report made clear).
> What's so wrong with pirq_eoi_map that you're trying to avoid it
> by all means?
The main issue is that if pirq_eoi_map is enabled PHYSDEVOP_eoi
automatically unmask the event channel.
There isn't even a way to specify if we want the unmask to be done or
not, it just does it.

I also think that it is a violation of the interface, see this comment
from xen/include/public/xen.h:

     * Event channels are addressed by a "port index". Each channel is
     * associated with two bits of information:
     *  1. PENDING -- notifies the domain that there is a pending notification
     *     to be processed. This bit is cleared by the guest.
     *  2. MASK -- if this bit is clear then a 0->1 transition of PENDING
     *     will cause an asynchronous upcall to be scheduled. This bit is only
-->  *     updated by the guest. It is read-only within Xen. If a channel
     *     becomes pending while the channel is masked then the 'edge' is lost
     *     (i.e., when the channel is unmasked, the guest must manually handle
     *     pending notifications as no upcall will be scheduled by Xen).

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>