Prev: How to run 1394 Async/Isoch Commands for DDK sample???
Next: Windows Vista Add printer driver Error (0x00000003)
From: Don Burn on 17 Jan 2007 18:24 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 19 Jan 2007 19:25 > > 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 25 Jan 2007 19:46
> 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... |