Hello,
If you’re going to use only MSI interrupt, WDK 7660 (KMDF v1.09) is totally
enough.
But taking into account your question about MSI-X interrupt, I can say that
basic support of this kind of interrupt on the framework level implemented
only for NDIS driver.
Correct me if I’m wrong but I’ve checked this several times and I’ve
examined corresponding sources from the WDK collection.
With respect to MSI interrupt, I’ve sorted out with them.
Basically, all that necessary to do, you have correctly prepare the driver
inf-file and in the right way make initialization of interrupt object.
Number of interrupt objects in given case should be equal to the number of
supported MSI vectors.
In other words, you have to allocate multiple instances of interrupt
object, one instance per MSI vector.
After this important step you can see the reaction of the Windows kernel on
you setup in the WinDbg with aid of the following commands:
!wdfkd.wdftmffile c:\WinDDK\7600.16385.1\tools\tracing\amd64\Wdf01009.tmf
!wdflogdump
If everything has been done correctly, you’ll see how system allocate the
number of MSI vectors that you previously pointed in the inf-file.
Within the configuration space of the your device there is a one dedicated
location called MSI Capability Structure.
In this structure there is a 16-bit register MSI Control. Exactly this
register serves for configuration of interrupt system used by the Host PC.
By default, only legacy interrupt (INTx) support is configured. If you
would like to use MSI or MSI-X your have to point this in the inf-file.
By the way, configuration for MSI/MSI-X interrupt in inf-file has not some
differences, it’s almost the same.
In other words, it’s not a matter of OS support, it’s mainly a matter of
capability of your HW.
OS system just provides a mechanism of configuration configuration space of
particular device.
And handling interrupt from this device via PCIe interface.
Necessary just properly configure MSI Control register depends on the
capability of your device.
After the loading of your driver, system will reconfigure the interrupt
system based on the settings in your inf-file.
For MSI-X interrupt system within the configuration space there is another
location called MSI-X Capability Structure.
Here you have also quite the same registers set, namely: Message Control,
Table Offset and PBA(Pending Bit Array) Offset.
Unlike the MSI interrupt, for MSI-X natively (by the design) can be assign
corresponding priority and in which connection, this priority will be
handle by the Root Complex.
In the case of MSI, you also has such functionality but it’s implemented on
the Windows kernel level (allowed for you specify the logical CPU core,
priority and affinty - WdfInterruptSetPolicy())
MSI interrupt support I’ve implemented and tested (8 MSI vectors,
Motherboard based on the Q87 chipset and Haswell CPU with 4 logical cores
without Hyper-Threading feature support, PCIe gen2 x8).
But MSI-X support I guess required corresponding support from the OS
because you have to manage interrupt table register and PBA register. At
least during the configuration stage.
NDIS network driver library provides such APIs. But if you’re develops
ordinary bus driver such APIs are absent.
That’s why I decided to proceed use MSI instead of MSI-X.
Except of prioritizing MSI-X has another important feature - it’s can
support much more (for modern Windows kernel this limit a bit less that
2048) than 32 interrupt sources (it’s limit for MSI by the way).
Certainly most of this information you can take from the PCIe
specification. But still important is support from the OS side.
And with the support of MSI-X it’s still remaining not clear how this is
implemented by KMDF for PCIe bus driver not for NDIS.
Best Regards,
Dmitry
On Tue, Dec 13, 2016 at 3:38 AM, wrote:
> Hi, Tim:
> Yes, my WDK version is too old, it’s KMDF version is 1.09.
> So I need to update WDK to 8.0 or 10 to update KMDF 1.11.
> But I was confused by the WDK document which stated WDK 7600 supported MSI
> interrupt totally. And I suspected if WDK 10 can solute my problem. That is
> registered IMSR for my device to support more interrupt signals.
> Thanks
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:></http:>