[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [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 pre-registered > interrupt vector (this is most like MSI, except the interrupt wouldn't be > 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 XP. Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |