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] Interrupt forwarding

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Interrupt forwarding
From: Jon Smirl <jonsmirl@xxxxxxxxx>
Date: Sat, 12 Mar 2005 13:53:58 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, ian.pratt@xxxxxxxxxxxx
Delivery-date: Sat, 12 Mar 2005 19:22:11 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ArLXBO/QD6l8YqFkxMX3rxJin825LATwEERjH+FNu1S/tjZ6ACWYdbm5EdVAqJGwy8or2iOjOJ+09jriMa2BwAlXs53LCw7PkA2s2O159KpcJNnk+OM9JZqYJrnQ+bnn4LQ006eiSC9JrdM+pQsLmCIOhMcZjl3eYMMS1vg0DXU=
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <f7ad8bba837b5b01bf13f789a612118f@xxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D1E3602@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <d10e560f7d2d0190ed351d1955f129c5@xxxxxxxxxxxx> <9e47339105031210332d8756f0@xxxxxxxxxxxxxx> <f7ad8bba837b5b01bf13f789a612118f@xxxxxxxxxxxx>
Reply-to: Jon Smirl <jonsmirl@xxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
On Sat, 12 Mar 2005 18:48:53 +0000, Keir Fraser
<Keir.Fraser@xxxxxxxxxxxx> wrote:
> On 12 Mar 2005, at 18:33, Jon Smirl wrote:
> >> Shared interrupts are slightly worse because the irq won't get
> >> unmasked
> >> until all receivers say their work is done. If one lock sup it starves
> >> the rest -- until this is detected and that domain gets blown away.
> >
> > After you blow away the domain how do you acknowledge the interrupt?
> > Is all hardware required to have a tiny driver in the supervisor to
> > handling acking in this case? If you don't ack it, it is going to keep
> > interrupting.
> We don't go that far. A sensible approach would be to require the
> driver to be restarted, and to reset the hardware device, before
> unmasking. Or to rate limit each interrupt line to an
> administrator-configurable 'reasonable' number of IRQs per second --
> this might also catch bugs where drivers are not properly acking
> devices for other reasons.

In x86 boxes almost everything is shared. Leaving the interrupt masked
off will probably disable 20% of the hardware in the box.

Jon Smirl

SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
Xen-devel mailing list