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: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Losing PS/2 Interrupts
From: Thomas Goetz <tcgoetz@xxxxxxxxx>
Date: Mon, 23 May 2011 14:39:24 -0400
Cc: Simon Graham <simon.graham@xxxxxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Jan Beulich <JBeulich@xxxxxxxxxx>, Konrad Rzeszutek Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Mon, 23 May 2011 11:40:18 -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=wg+6KGqInwIQIcd7BW/VUSVF5GzJxNrwXQnE+o0Daoc=; b=BfQJGmzAAYWRzZKpzBsstq0om1pCei6txcGkgiaa8Puxdk0s1WHv/FQunKZIm1kIDs +ACYSGgbAD7jVeiBAR6HjA1GJqILdCkLm5VIPRL3epi/d9ISoionDD98lYUOT+aO7bui 1t21vsGrY5nsiOQRQ9byDb+u7I5uLWDx9aJuI=
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=Mo1EFmU9ub2fVmJ9oh6FMn2dyurRoiqysAc8XnwNprL7N1jDJb/G6dUWE7M7sj8JPP YF3xVBbgYQQrq8xJWhxItGOmTyX8mvDrvvvRPNOw4nWiVQwI5FMFeLrG32cmTnlV+6B5 Mf/4slWWsTA4zP4E0HdDmAgJBmhwAQO8hqqnA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8BA7030-8E00-4E8F-B82F-486966306818@xxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On May 23, 2011, at 1:28 PM, Thomas Goetz wrote:

> On May 23, 2011, at 1:16 PM, Thomas Goetz wrote:
>> On May 23, 2011, at 9:45 AM, Stefano Stabellini wrote:
>>> On Mon, 23 May 2011, Thomas Goetz wrote:
>>>> My assumption is that at the point that the i8042 driver reads the data 
>>>> register a new interrupt happens. There is gap in
>>>> time between when the data register is read and when the event channel 
>>>> pending state is cleared. Since the hypervisor
>>>> ACKed the previous real interrupt before delivering it to the guest, there 
>>>> is nothing to stop the i8042 device from
>>>> interrupting immediately after the data register is read. If it interrupt 
>>>> before the event channel pending state is
>>>> cleared, then it will not be delivered to the guest and the EOI mechanism 
>>>> will be set up, but I haven't found anything in
>>>> that that will set up a delayed delivery of the second interrupt.
>>>> In this situation the i8042 device has every reason to believe the second 
>>>> interrupt will be delivered. The previous
>>>> interrupt was received and handled. Nothing is masked.
>>>> Am I missing something?
>>> I am assuming you have the latest version of my fixes to
>>> drivers/xen/events.c
>> I'll have a version ported from your 2.6.39 tree to my 2.6.38 tree. I'll 
>> update my copy of your tree and make sure it's up to date.
>>> The problem you are describing shouldn't happen because the interrupt
>>> handler returned by request_irq to i8042 is handle_edge_irq that calls
>>> chip->irq_ack() before handle_irq_event().
>> I checked on which method it is using and it's using handle_fasteoi_irq. In 
>> fatc all of the IRQs under 16 are despite most being edge. Log snippet 
>> below. I'm looking into why pirq_needs_eoi is returning the wrong answer now.
> pirq_needs_eoi checks info->u.pirq.flags & PIRQ_NEEDS_EOI. PIRQ_NEEDS_EOI is 
> only set by pirq_query_unmask which sets it based on the hypercall 
> PHYSDEVOP_irq_status_query which in Xen 4.0.1 and Xen unstable always returns 
> an EOI is needed. Stefano, I don't see any changes in your 2.6.39 tree that 
> would effect this.

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);

Tom Goetz

Xen-devel mailing list