[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Multiple IRQ's in HVM for Windows

  • To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
  • Date: Fri, 26 Dec 2008 21:54:01 +1100
  • Cc:
  • Delivery-date: Fri, 26 Dec 2008 02:54:31 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AclnCjPkeAYvm5WbTaqM+PmGGNFiHQAIdYQ3AAU6BeAAATbLsQAADYFA
  • Thread-topic: [Xen-devel] Multiple IRQ's in HVM for Windows

> Or we could bypass the INTx emulation entirely, and deliver per-cpu
> event_pending status to that HVM VCPU's local APIC, on a
> interrupt vector (this is most like MSI, except the interrupt wouldn't
> coming from a PCI device, although we could perhaps even fake that out
> too).
> There's quite a few options.

How many interrupts do we have to choose from here? I was able to get
Windows to use up to (I think) IRQ31.

As I understand it, most of the 'protocol' we are talking about is based
around the shared_info_t structure, which appears to make the assumption
that there is a single point of entry for event delivery into a domain.
To make use of multiple IRQ's we'd have to check every single event bit
right? Is that a performance problem.

The reason all of this comes up btw, is that Windows is a PITA. What I
do in my PV drivers is attach each device (xen platform pci driver, vbd
driver, net driver, scsi driver, etc) to the same interrupt. The
platform driver attaches first and gets called first. It clears the
pending flag etc in the normal way, but where the event channel is
registered as wanting delivery via an ISR, it sets a corresponding event
channel bit in a private area, and then tells Windows that the interrupt
was not actually for that device afterall, which prompts Windows to call
the next ISR in the chain. That ISR (eg the vbd driver) check's its bit
in the private area and does it's ISR code if the bit is set, and then
tells Windows that the interrupt was not for that device, and so on.
When Windows is using one of the ACPI HAL's all this works fine. However
when Windows is using the 'Standard PC' HAL, I stop seeing interrupts
for the network device very soon after boot. I think that because of all
this 'interrupt not for me'-ness going on, Windows thinks that spurious
interrupts are occurring and stops calling the network ISR except for
every 3-20 interrupts. I can work around it, but that kind of behaviour
makes me think that maybe I'm going around things the wrong way...

For the network device I have gone back to using a direct callback, but
if I ever want to get these drivers WHQL certified (and I do
eventually), that sort of thing won't fly without a whole lot of
explaining. And for storage devices using the scsiport framework, an
interrupt is the only way to do it. The storport framework is a
possibility but currently it seems too broken and isn't available under



Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.