The miniport driver I am working on is for an Ethernet device. The
device supports MSI interrupts. Though, I have not been able to enable
MSI interrupts on Vista so far.

The driver sets MsiSupported to TRUE and sets required MSI handlers
when it calls NdisMRegisterInterruptEx.

The INF file adds the following registry values. According to the
white paper on interrupts (MSI.doc available on microsoft web site),
MSISupported is required. Is this true?

HKR, "Interrupt Management", 0x00000010
HKR, "Interrupt Management\MessageSignaledInterruptProperties",
0x00000010
HKR, "Interrupt Management\MessageSignaledInterruptProperties",
MSISupported, 0x00010001, 1
HKR, "Interrupt Management\MessageSignaledInterruptProperties",
MessageNumberLimit, 0x00010001, 16

Am I missing something? Has anyone been able to use MSI interrupts on
Vista? Any clue is welcome...

I forgot to mention the machine I am using. The machine is a
dual-Opteron. Vista runs in 64-bit mode. On the same machine and
using the same Ethernet device, I can enable MSI interrupts on Linux.
So, the machine is capable of handling MSI interrupts.

John wrote:

MSI works for NDIS 6 drivers in Vista. We have NIC drivers that do MSI just
fine. How many MSI messages do you ask for?

Use NdisSetOptionalHandlers to register PnP handlers for your miniport
driver (see NDIS_OBJECT_TYPE_MINIPORT_PNP_CHARACTERISTICS). In your
MiniportFilterResourceRequirementsHandler check to see if you get MSI
resources.

-ali

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"John" <hykim@rice.edu> wrote in message
news:1168994386.247045.295550@11g2000cwr.googlegro ups.com...

Thanks for the reply. The original INF file added the registry entries
(MSISupported) in DDInstall section, not DDInstall.HW section. Adding
those entries in DDInstall.HW section enabled MSI interrupts.

Here's follow-up questions.

In MiniportFilterResourceRequirements, IO_RESOURCE_REQUIREMENTS_LIST
has "AlternativeLists" field. It looks like if the device has both
MSI-X and MSI capabilities, then AlternativeLists is set to 2. List[0]
seems to include only MSI-X interrupt resources, and List[1] includes
MSI and also legacy INTx interrupts. What's the purpose of having
multiple lists?

Also, "Count" of List[1] seems to be incorrect. Its value indicates
that there are a lot more Descriptor entries in List[1] than "ListSize"
of IO_RESOURCE_REQUIREMENTS_LIST indicates. If I just rely on "Count"
field, memory access does go out-of-bound and leads to kernel panics...
Am I even supposed to examine the second list? Thanks...

Alireza Dabagh [MS] wrote:

Sorry, I am not familiar with the exact format of the interrupt resources.
hopefully somebody knowledgeable see this and steps in. You may also want to
open a new thread with the right title to make this more visible.

-ali

--
This posting is provided "AS IS" with no warranties, and confers no rights.

I'm not a pro, but I believe the reason for the two lists is that depending
on the configuration and available machine resources you can get MSI or a
regular interrupt. I would ask the question specifically about MSI as
Alireza suggested, and you might copy it the NTDEV list at
http://www.osronline.com/ since I know some of the folks involved with the
Vista MSI implementation respond to questions there.

--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply




"Alireza Dabagh [MS]" <alid@online.microsoft.com> wrote in message
news:45aeae94@news.microsoft.com...

Not sure this is going to answer your question but let me tell you what I
learnt when I wrote the filter-resource-requirement parsing function in KMDF
to support MSI. I will mix little bit of KMDF concepts here. I hope it
doesn't confuse you that much.

In framework, you create interrupt objects upfront in the AddDevice routine.
If your device supports MSI then you create one interrupt object for every
message the device is build to support. You specify the policy such as
affinity, priority for your interrupt when you create the object. When the
framework receives IRP_MN_FILTER_REQUIREMENTS, it processes the entire list
and applies the policy of the interrupt object in the descriptor. Since you
don't know which descriptor (preferred or alternate) from which list is
going to get assigned by the system, you have to look at every one of them
and figure out which KMDF interrupt object this would match to if it were
assigned by the system, and set the policy provided by the driver. It's a
complex logic. The basic rule I follow when I parse the descriptor is as
follow:

1) An IO_RESOURCE_REQUIREMENTS_LIST (aka IoResourceRequirementList) can
contain one or more IO_RESOURCE_LIST (aka IoResourceList).
2) Each IoResourceList can have one or more IO_RESOURCE_DESCRIPTORs (aka
resource descriptor).
3) A resource descriptor can be default (IO_RESOURCE_DEFAULT), preferred
(IO_RESOURCE_PREFERRED), or alternate (IO_RESOURCE_ALTERNATIVE). This is
coded in the Options field of the descriptor.
4) A preferred descriptor can have zero or more alternate descriptors (P, A,
A, A..). If the system cannot assign a preferred descriptor then it will
assign the alternate one.
5) In an IoResourceList, there can be one or more line based interrupt (LBI)
descriptors (P,A,P,A).
6) In an IoResourceList, there can be only one preferred MSI 2.2 (single or
multi message) descriptor.
7) In an IoResourceList, there cannot be MSI2.2 and MSI-X descriptors.
8) In an IoResourceList, there can be one or more MSI-X descriptor.
9) In an IoResourceList, there can be one or more MSI-X descriptor and an
alternate LBI descriptor. This alternate LBI descriptor is picked if the
system cannot assign any MSI-X descriptor.

-Eliyas

Thanks a lot for the details. The device has both MSI-X and MSI
capabilities.
I've verified that IoResourceRequirementList contains two
IoResourceList's.
The first IoResourceList includes MSI-X interrupt descriptors (Option
is set to 0)
and one LBI descriptor (Option is set to Alternative). The second
IoResourceList
includes one MSI interrupt descriptor (Option is set to Preferred) and
one LBI
descriptor (Option is set to Alternative). These make sense to me now.

Is there any way to tell whether an MSI descriptor is for an MSI-X or
MSI interrupt?
Descriptor itself only tells if it is MSI or LBI. Above, I know that
the first list contains
MSI-X interrupt descriptors only because the number of descriptors
matches the
number of MSI-X messages that the device supports.

I've been trying to force the use of MSI. So far, it appears that
Windows always
enables MSI-X not MSI. Even if I remove the first IoResourceList (that
contains
all MSI-X interrupts) from IoResourceRequirementList in
MiniportFilterResourceRequirements, Windows still enables MSI-X,
apparently
because the second list contains one MSI interrupt descriptor.

Thanks...