WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Losing PS/2 Interrupts
From: Thomas Goetz <tcgoetz@xxxxxxxxx>
Date: Tue, 24 May 2011 11:37:05 -0400
Cc: Simon Graham <simon.graham@xxxxxxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Konrad Rzeszutek Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Tue, 24 May 2011 08:46:16 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Rf4iMbgfdJYgMGjguHnEzLXU1/rUljSlvhny6/cbVuY=; b=l3KkfFEFichw1ID6iO0dQrIo4XNMzdNI5D9mwDysUG9EtNdqNubP4ovGBoXX1Ahf0I vz/FbVMmPE/0DIEDT4kNDr6jFHEeLh2NOryGnQQqvl75MM90Aoe9gmDDvfvl2q9sX/Ez WoChW0gHQ0y8KHiXe3sZyw2NhkX8WwUnbsiyw=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=xOUUZcGwPXHFMzVgYCNm/87ULTdbrdxxWXnGmMrcy3TD63usFJNCpHYEd7U1laB0WM egDW6zb/2OrN4Ls716V8Gnb7XAlsqYEn3OB4x8biCXGAJ0wnnDNXBqn90Zjkd+cJaES1 ysuVn1PBminrjkNTJFDb/gsXBs+hpE1+wgMqw=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1105241204490.12963@kaball-desktop>
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> <1BDCDA76-92F8-42F6-8A65-F1BC48378485@xxxxxxxxx> <alpine.DEB.2.00.1105241204490.12963@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On May 24, 2011, at 9:53 AM, Stefano Stabellini wrote:

> On Mon, 23 May 2011, Thomas Goetz wrote:
>> I'm running with the attached workaround and I'm the PS/2 issue is gone.
>> 
>> drivers/xen/events.c :: xen_map_pirq_gsi
>> 
>>        if ((strcmp(name, "ioapic-edge") != 0) && pirq_needs_eoi(irq)) {
>>                set_irq_chip_and_handler_name(irq, &xen_pirq_chip,
>>                                handle_fasteoi_irq, name);
>>        } else {
>>                set_irq_chip_and_handler_name(irq, &xen_pirq_chip,
>>                                handle_edge_irq, name);
>>        }
> 
> I had the same idea while reading your previous email.
> I think the following patch is better than strcmp name:
> 
> ---
> 
> Use the trigger info we already have to choose the irq handler
> 
> Do not use pirq_needs_eoi to decide which irq handler to use because Xen
> always returns true if the guest does not support pirq_eoi_map.
> Use the trigger information we already have from MP-tables and ACPI.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 7f676f8..8418398 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -627,6 +627,9 @@ int xen_allocate_pirq_gsi(unsigned gsi)
>  *
>  * Note: We don't assign an event channel until the irq actually started
>  * up.  Return an existing irq if we've already got one for the gsi.
> + *
> + * Shareable implies level triggered, not shareable implies edge
> + * triggered here.
>  */
> int xen_bind_pirq_gsi_to_irq(unsigned gsi,
>                            unsigned pirq, int shareable, char *name)
> @@ -665,16 +668,13 @@ int xen_bind_pirq_gsi_to_irq(unsigned gsi,
> 
>       pirq_query_unmask(irq);
>       /* We try to use the handler with the appropriate semantic for the
> -      * type of interrupt: if the interrupt doesn't need an eoi
> -      * (pirq_needs_eoi returns false), we treat it like an edge
> -      * triggered interrupt so we use handle_edge_irq.
> -      * As a matter of fact this only happens when the corresponding
> -      * physical interrupt is edge triggered or an msi.
> +      * type of interrupt: if the interrupt is an edge triggered
> +      * interrupt we use handle_edge_irq.
>        *
> -      * On the other hand if the interrupt needs an eoi (pirq_needs_eoi
> -      * returns true) we treat it like a level triggered interrupt so we
> -      * use handle_fasteoi_irq like the native code does for this kind of
> +      * On the other hand if the interrupt is level triggered we use
> +      * handle_fasteoi_irq like the native code does for this kind of
>        * interrupts.
> +      *
>        * Depending on the Xen version, pirq_needs_eoi might return true
>        * not only for level triggered interrupts but for edge triggered
>        * interrupts too. In any case Xen always honors the eoi mechanism,
> @@ -682,7 +682,7 @@ int xen_bind_pirq_gsi_to_irq(unsigned gsi,
>        * hasn't received an eoi yet. Therefore using the fasteoi handler
>        * is the right choice either way.
>        */
> -     if (pirq_needs_eoi(irq))
> +     if (shareable)
>               irq_set_chip_and_handler_name(irq, &xen_pirq_chip,
>                               handle_fasteoi_irq, name);
>       else
> 


I tested this patch and it worked fine for me. It will go into nightly testing 
tonight and I'll let you know if we hit any issues.

---
Tom Goetz
tcgoetz@xxxxxxxxx





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