RE: [Xen-devel] trigger an interrupt in HVM

["Cui, Dexuan" <dexuan.cui@xxxxxxxxx>]

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 :)

Thanks,
-- 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.

Thanks

James


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel