Is anyone aware of how HT interrupts are handled on Windows? I couldn’t find much on this part on the web. HT devices make use of MSI(Message Signaled Interrupts) to generate interrupts. It involves writing in the configuration space. How are these configuration writes converted into interrupts on Windows? Logically they should be mapped to some IRQs but I am not sure how it happens.
First of all, there is no support for MSI on OS versions below Vista, so that your driver will be unable to take advantage of MSI capability if you run it on earlier OS versions.
How are these configuration writes converted into interrupts on Windows?
Check Volume 3 of Intel Developer’s Manual - it explains what makes MSI tick. Basically, your device has to write the contents of the Message Data Register (where interrupt vector is specified) to the address that is contained in the Message Address Register…
Logically they should be mapped to some IRQs but I am not sure how it happens.
IRQs and MSI are totally unrelated things. When you use MSI IOAPIC that maps IRQs to vectors is not involved (in this context IRQ means IOAPIC pin, which is not necessarily the same IRQ that is used by PIC). The system obtains Cthis mapping from BIOS tables. Ceck MP Specifications for more info…
Anton Bassov
I have checked MSI mechanism from “PCI System Architecture”. As you said, the device needs to use the Message Data Register and Message Address Register to generate the interrupt. On its journey to the CPU, it goes as a configuration space write till it reaches the NorthBridge where it is converted to a CPU understandable interrupt i.e IRQ. Is that correct??
I am not clear about how the CPU will take this interrupt to the driver’s interrupt routine. That is why I thought there might be some IRQ mapping there which takes care of finding the Interrupt routine. I checked the linux source code(htirq.c) and it does something of similar sort.
> I am not clear about how the CPU will take this interrupt to the driver’s interrupt routine.
I think I got the solution to this. I am writing a storport miniport driver. The PORT_CONFIGURATION_INFORMATION structure has a member named HwMSInterruptRoutine which is a callback for Message Signaled Interrupts. The documentation says whenever the HBA generates MSI, the corresponding routine will be called.
The only dilemma now is, the documentation talks this with respect to HBAs on the PCI-X bus but I want it for a device on the HT bus. Will it work for the HT bus HBAs in the similar fashion?
> I am not clear about how the CPU will take this interrupt to the driver’s interrupt routine.
Target vector is specified in Message Data Register…
The PORT_CONFIGURATION_INFORMATION structure has a
member named HwMSInterruptRoutine which is a callback for Message Signaled Interrupts.
Don’t confuse ISR with interrupt handler in IDT - the latter invokes the former after having saved execution context and raising IRQL to DIRQL…
Anton Bassov
MSI showed up first on PCI-X (at least in any real implementation.)
But the mechanisms are very similar for HT and Windows supports both,
as well as PCIe and devices which aren’t on any of the above.
- Jake Oshins
P.S. Anton was right about most of your other questions, so I’ll
forgo addressing them.
wrote in message news:xxxxx@ntdev…
>> I am not clear about how the CPU will take this interrupt to the
>> driver’s interrupt routine.
>
> I think I got the solution to this. I am writing a storport miniport
> driver. The PORT_CONFIGURATION_INFORMATION structure has a member
> named HwMSInterruptRoutine which is a callback for Message Signaled
> Interrupts. The documentation says whenever the HBA generates MSI,
> the corresponding routine will be called.
> The only dilemma now is, the documentation talks this with
> respect to HBAs on the PCI-X bus but I want it for a device on the
> HT bus. Will it work for the HT bus HBAs in the similar fashion?
>
Jake,
I couldn’t find any documentation or APIs in the WDK for HT interrupts. WDK only talks about Message Signaled Interrupts. For instance, In the Storport Interface there is a mechanism defined for a miniport driver to support Message Signaled Interrupts.
HT interrupts are similar to MSI, but not the same. So, Can I assume that the APIs and Interfaces defined for MSI should be used in the similar fashion for HT interrupts. Do I need to consider anything else?
Smit,
Vista only supports devices that have a PCI MSI (or MSI-X) capability in config space. An HT MSI capability is a different block of registers that Windows does not support. Basically all HT systems these days have chipsets that contain a “HT MSI Mapping Capability,” which the OS can program to tell it how to convert PCI MSI’s to HT interrupt messages. Vista does support this. But this is really for PCI devices on HT systems, not directly for HT devices. I tend to doubt that chipsets have converters in place for HT devices.
I think your options are:
- try to figure out if you can implement a converter internal to your device by looking at the HT specs for converters.
- filter in the message-signaled interrupt requirements yourself, and manually program the HT interrupt capability. I don’t believe requirements filtering is available to storport miniports, so this might not actually be an option.
Dave
Hi all,
This is wrt to the HT interrupts discussion. (
http://www.osronline.com/showthread.cfm?link=126356)
In that Dave explained about using HT-MSI mapping
for the HT interrupt handling.Since we are looking at a
HT device on HT BUS(not a pci device on HT systems)
without having converter. Is there a way we can handle interrupts?
[1] Can we do a IO-APIC manipulation for handling HT interrupt messages?
We want to know how we can configure IO-APIC in windows to handle the HT
message. Even we are ready to write more than one driver to handle these
scenerios.
[2] We can use HT Capability Block for writing the vector
to hardware. Is there way to use CONNECT_FULLY_SPECIFIED version of
IOConnectInterrupEx for handling this ?
[3] We want know how we can utilize resource requirement filter
in storeport miniport drivers?
Ganesh Gudigara