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] [RFC] Pass-through Interdomain Interrupts Sharing (HVM/D

To: Guy Zana <guy@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] Pass-through Interdomain Interrupts Sharing (HVM/Dom0)
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Fri, 10 Aug 2007 08:01:42 +0100
Cc: Alex Novik <alex@xxxxxxxxxxxx>
Delivery-date: Thu, 09 Aug 2007 23:58:16 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <9392A06CB0FDC847B3A530B3DC174E7B0327CC08@xxxxxxxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcfarSF45lhECFFTQSiE3oBAG7IKmQAbyytW
Thread-topic: [Xen-devel] [RFC] Pass-through Interdomain Interrupts Sharing (HVM/Dom0)
User-agent: Microsoft-Entourage/
On 9/8/07 18:45, "Guy Zana" <guy@xxxxxxxxxxxx> wrote:

> The main idea here is to inject the interrupt into Dom0 when we don't
> know what to do with it. If Dom0 takes the ownership, then let it handle
> the interrupt. If not, we inject it into the HVM. We recognize that all
> of the PT devices are not asserting the line by PLINE deassertion or by
> Dom0 taking the ownership back to it.

This needs dom0 kernel changes and does not solve the general sharing
problem (among multiple HVM domains, or among HVM domains and PV domains
other than dom0). Could you somehow track which guest is most likely to
handle the interrupt, deliver to it first, and then detect the immediate
re-interrupt if it EOIs without handling? Plus have a timeout if it does not
EOI in reasonable time?

 -- Keir

Xen-devel mailing list