From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Goetz Subject: Re: Re: Losing PS/2 Interrupts Date: Mon, 23 May 2011 08:09:35 -0400 Message-ID: <1D3BFCDD-9D53-48BA-9ECD-D009AD535C2B@gmail.com> References: <3E2050B5-59DC-4E4F-9C8D-8C04A6B465EB@gmail.com> <20110520175044.GA30367@dumpdata.com> <5D477258-8216-48BD-8A93-186E044118B9@gmail.com> <4DDA366E0200007800042C71@vpn.id2.novell.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/mixed; boundary="===============1714061683==" Return-path: In-Reply-To: <4DDA366E0200007800042C71@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: Simon Graham , xen-devel@lists.xensource.com, Konrad Rzeszutek Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org --===============1714061683== Content-Type: multipart/alternative; boundary=Apple-Mail-30--719622581 --Apple-Mail-30--719622581 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 23, 2011, at 4:26 AM, Jan Beulich wrote: >>>>=20 >>=20 >> The PS/2 port has a one character buffer. It will only ever send one=20= >> interrupt until it has been serviced. When __do_IRQ_guest calls=20 >> send_guest_pirq and sees that it is already pending, what part of the = between=20 >> the bottom of __do_IRQ_guest and _irq_guest_eoi results in the = pending=20 >> interrupt being issued to the guest? I haven't found that and it = looks like=20 >> Xen is merging the ACKTYPE_NONE edge interrupt resulting in the deice = never=20 >> being serviced when it's buffer is full and never interrupting again. >=20 > It would be a bug of the 8042 if it sent a second interrupt when the > first one wasn't serviced (status and data port read) yet. It's the > nature of edge triggered interrupts that secondary instances are > lost when the primary instance doesn't get handled (in time). >=20 > Jan >=20 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? --- Tom Goetz tcgoetz@gmail.com --Apple-Mail-30--719622581 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


The = PS/2 port has a one character buffer. It will only ever send one =
interrupt until it has been = serviced. When __do_IRQ_guest calls
send_guest_pirq and sees that it is already pending, what = part of the between
the = bottom of __do_IRQ_guest and _irq_guest_eoi results in the pending =
interrupt being issued to the = guest? I haven't found that and it looks like =
Xen is merging the = ACKTYPE_NONE edge interrupt resulting in the deice never =
being serviced when it's = buffer is full and never interrupting again.

It = would be a bug of the 8042 if it sent a second interrupt when = the
first one wasn't serviced (status and data port read) yet. It's = the
nature of edge triggered interrupts that secondary instances = are
lost when the primary instance doesn't get handled (in = time).

Jan


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?

---
Tom Goetz




= --Apple-Mail-30--719622581-- --===============1714061683== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1714061683==--