From: Don Burn on
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(a)online.microsoft.com> wrote in message
news:45aeae94(a)news.microsoft.com...
> 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.


From: Eliyas Yakub [MSFT] on
>
> 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?
>

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

From: John on

> 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...