The basic question: How is a vendor of PCI devices supposed to make multiple DEXTs that control subsets of PCI device IDs?
If one has a PCI vendor ID of 0xCDEF and two devices with device IDs of 0x1234 and 0x5678 that need two separate drivers, how are the DEXTs constructed to match accordingly? If each driver specifies an explicit IOPCIPrimaryMatch of 0x1234CDEF and 0x5678CDEF, then it seems the vendor would have to request special entitlements for each driver (and maintain them through Apple if additional models are added). Ugh. On the other hand, the dev portal now has some level of ability to build entitlements combinations during App ID creation via check boxes in the "Additional Capabilities" tab. Great, but selecting PCI Primary Match puts in a wildcard match of 0x0000CDEF&0x0000FFFF for the vendor ID. Thus the DEXT must be signed this way in order to load and will load against any of the vendor's devices. This would work if there was an IOService::Probe() method to filter out unwanted devices in each driver, but there isn't.
How is this supposed to work?
The PCIDriverKit entitlement 0x0000CDEF&0x0000FFFF would entitle a driver to be able to match on any device that has a vendor ID of 0xCDEF. The matching of specific devices occurs in your Info.plist, where you would match based on IOPCIMatch, IOPCIPrimaryMatch, IOPCISecondaryMatch, and/or IOPCIClassMatch. This would allow you to match devices to drivers based on their device ID/class code with identical entitlements.
So for your example of matching on devices based on VID + DID, you would give both drivers the wildcard match entitlement of 0x0000CDEF&0x0000FFFF, allowing them the right to match on that vendor ID. Then in the Info.plist of your driver, specify your matching parameter via IOPCIPrimaryMatch of 0x1234CDEF or 0x5678CDEF based on the driver. Your IOPCI_Match keys do not have to match your entitlements.
This could also be done in a single dext by giving each each IOKitPersonalities entry a different IOUserClass value. So your entry that matches on 0x1234CDEF might have an IOUserClass of "My1234Driver." While 0x5678CDEF matches to "My5678Driver." That way you can ship a single dext (and the customer only has to approve one dext) that matches a specific implementation to each specific device.
For extended context, USBDriverKit uses a similar tactic, where entitlements are given for Vendor IDs. A developer will likely want to match different drivers to different product IDs and that can be completed by entitling the driver with the vendor ID, and then customizing matching in the IOKitPersonalities to match a specific VID/PID combo to a specific IOUserClass implementation of their driver.
