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:04:50 +0100
Cc: Alex Novik <alex@xxxxxxxxxxxx>
Delivery-date: Fri, 10 Aug 2007 00:01:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2E1CBE6.C5CE%keir@xxxxxxxxxxxxx>
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: AcfarSF45lhECFFTQSiE3oBAG7IKmQAbyytWAAAcBIU=
Thread-topic: [Xen-devel] [RFC] Pass-through Interdomain Interrupts Sharing (HVM/Dom0)
User-agent: Microsoft-Entourage/
On 10/8/07 08:01, "Keir Fraser" <keir@xxxxxxxxxxxxx> wrote:

> 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?

My thought here is a simple priority list with move-to-back of the frontmost
domain when we deliver him the interrupt but he does not deassert the line
either in reasonable time or by the time he EOIs the interrupt. This is
simple generic logic needing no PV guest changes.

 -- Keir

Xen-devel mailing list