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] trigger an interrupt in HVM

To: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] trigger an interrupt in HVM
From: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
Date: Thu, 21 Aug 2008 11:04:44 +0800
Delivery-date: Wed, 20 Aug 2008 20:05:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D01490395@trantor>
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: <AEC6C66638C05B468B556EA548C1A77D01490392@trantor> <FE7BBCFBB500984A9A7922EBC95F516E019469EF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D01490395@trantor>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckDI/dJ8Vz6w8p3QGimRDvwpEL7eQADR9aQAAERcdAAAPjYIA==
Thread-topic: [Xen-devel] trigger an interrupt in HVM
Oh, sorry, I didn't realize you meant the case of PV driver.
I think PV drivers for Linux/Windows should be alike here?
(I haven't read any codes of the Windows PV drivers :)

-- Dexuan

-----Original Message-----
From: James Harper [mailto:james.harper@xxxxxxxxxxxxxxxx] 
Sent: 2008年8月21日 10:32
To: Cui, Dexuan; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] trigger an interrupt in HVM

> What's the reason to try this? :-)
> The interrupt injection into HVM guest doesn't use
evtchn_upcall_pending -
> - that's for PV guest.
> Maybe you can refer to tools/ioemu/hw/rtl8139.c to see how the rtl8139
> device model injects interrupt into hvm guest (pls see pci_set_irq()).

I should have been more clear. This is from inside the DomU with the
GPLPV drivers.

The various subsystems (xennet, xenvbd) hook onto the same IRQ as the
PCI device. When the PCI device gets an IRQ, signalling that an event
channel has been set, and the event channel is for one of the subsystem
devices, it tells windows that the IRQ wasn't handled, so windows then
tries the other devices.

Windows makes it very tricky to get 'into' the scsiport context, and an
interrupt is the easiest way to do this, so if the PCI device driver
wants to tell the vbd driver to prepare for a suspend, setting a flag in
some shared data and triggering an interrupt is a good way to do this.
The alternative is a scsiport timer that polls the shared data. The
latter works but is a bit ugly.

Previously, I was attaching the subsystem drivers to fake IRQ's (eg in
the range 31-47) and using the asm 'int x' instruction to call them.
This is really bad for performance and caused a few other problems too.



Xen-devel mailing list