Using controller device in driver to aggregate multiple related hardware devices

NTDEV
1

Hi Windows Driver Experts,

I have a requirement to aggregate multiple physical devices with same VID/DeviceID into a single unified controller DO to which clients can get handle, so that clients can have physical-device-agnostic implementation. I have found similar main thread on MSDN forums @ https://social.msdn.microsoft.com/Forums/sqlserver/en-US/41ef66ef-5e7e-4088-b225-b550eef89bb3/kmdf-bus-driver-pcie-child-devices?forum=wdk&prof=required which has been replied by Windows experts like Doron and Don. From the solutions proposed, I can make out that we can solve this requirement by having a separate DO which does not correspond to any particular physical device for this, and this can be a non-PnP CDO (control device object) or a virtual root-enumerated controller device ? both can solve the problem. I am more keen to use virtual root-enumerated PnP controller device because of following benefits which cannot be provided by non-PnP CDO:
? We can support device interfaces on PnP controller device and hence its easy for clients to get handle to the controller device by just waiting for GUID_DEVICE_INTERFACE_ARRIVAL notification.
? We have several clients running on top of base PnP driver, and we still would like individual physical devices to be disabled/enabled. So it?s very likely that we have active references to controller device taken by many clients, and hence controller device will not be able to delete when all physical devices are disabled. With non-PnP CDO, we will no longer be able to unload such driver in such scenarios. But with PnP CDO, we can still unload driver when we remove root-enumerated device from PnP manager.

Experts, please help me to get clarifications on below questions I have on ‘virtual root-enumerated PnP controller device’ approach I am planning to take to solve this design problem:
? Can I have the same driver expose the root enumerated virtual PnP controller device and also support multiple physical devices, instead of having different drivers for both ?
? Do you perceive such solution as non-standard with which we can get into any potential issues in future ?
? Are there any bad WHQL certification implications if we go for such approach ? Basically we are more inclined to have a solution without introducing an extra driver.
? Do we have to run WHQL tests on this virtual root enumerated PnP device also to get driver certified ?
? Do we have any drivers in Windows world that follows similar approach which I outlined here ?

I do agree that using non-PnP controller device have below benefits:
? No need to make extra efforts in installer/uninstaller and driver INF to add support for virtual PnP controller device.
? Virtual PnP device will only load driver at system startup even if there are no active/enabled physical devices related to the hardware. But with non-PnP CDO, driver will only load on detection of physical device and CDO will be created on 1st EvtDeviceAdd.
But I feel that the disadvantages outlined in the beginning overweighs the benefits. Especially I am not able to understand how the below user-case will work when using non-PnP CDO. Can experts here clarify on the below use-case also if we use a non-PnP CDO ?
? 2 physical devices detected, PnP loads the driver and call EvtDeviceAdd for each. In first EvtDeviceAdd, CDO also created and symbolic link created over it (for clients to use).
? Several clients got handle to the CDO and started using the device by issuing IOCTLs to that.
? Both devices get disabled one by one. At last device?s removal handling, WdfObjectDelete() is called on CDO to delete it but it will not get deleted because clients have active references to it. As a result, driver will also not get unloaded and cannot be unloaded again unless another physical device PnP removal gets triggered somehow.
? A physical device comes up again. I guess we are supposed to create a new CDO since we already called WdfObjectDelete() on old CDO, right ? Also if we do that, then does that mean that existing clients will keep on issuing IOCTLs to older CDO whereas new clients will get newly created CDO ? Also, does that mean that driver have to track the IO queue of the older [WdfDeleteObject() triggerred but not deleted yet] CDOs and current alive CDO ?

2

Doron Holan, Don Burn, Anton Bassov, Chris Aseltine ?? Can anyone chime-in here to provide the inputs ?

3

I’ll say something. In most cases, I think what you want to do is a bad idea, and there are cases where to may be appropriate. An example, the driver responsible for disk striping/mirror/raid essentially collects multiple storage devices below it, and exposes some different conglomerate device above it. Same goes for network failover drivers. IN these cases, the thing exposed is not not directly the underlying devices, but some virtualized device using the resources of all the the underlying devices.

Some years ago I worked on a set of drivers that uses the services of the original Windows OFED Infinband stack. In the original versions of this, multiple underlying hardware controllers were exposed through a single root enumerated driver. The interface to this root enumerated driver included ways to enumerate and select which of the underlying devices you were getting services from. This architecture proved problematic over time, and it had to be shifted to something that worked with the PnP device hierarchy. A big problem was device shutdown ordering, and startup ordering for boot devices (we had virtual disks). It problematic that if you were a client of the interface driver, you had no way of knowing when ALL the underlying devices were up, you just had to have a timer that waited for a while and then declared the set of underling devices complete. A client driver not being in the PnP hierarchy of it’s logical parent was also problematic if you wanted to disable a low level driver, like when you update the driver. In a normal PnP hierarchy, the PnP manager that parents always have to be disabled after all the children.

In the end, to make sure the low level driver was not shutdown until the virtual boot disk driver had flushed it’s last blocks required moving the architecture to fit with the PnP hierarchy. There are some ugly workarounds, which last I knew were used by the software iSCSI initiator, which basically involved the OS telling all NIC devices to shutdown late in the power down sequence. The iSCSI initiator is not in the PnP hierarchy of NIC devices, and the TCP stack is basically a root enumerated interface driver.

The reason the drivers originally had the architecture of funneling though a single interface driver was because that’s how the Linux drivers did it.

So, I have to ask if you want your conglomerate interface driver because there is a really good functionality reason, like the software raid driver, or do you want it because you have 300K lines of Linux code and you think it will be easier porting if you just make the architecture the same for Windows as it was on Linux?

That’s my $0.02 on the topic. Been there done that, don’t do it, except when there is a good reason to.

Jan

On 10/15/15, 12:10 PM, “xxxxx@lists.osr.com on behalf of xxxxx@gmail.com” wrote:

>Doron Holan, Don Burn, Anton Bassov, Chris Aseltine ?? Can anyone chime-in here to provide the inputs ?
>
>—
>NTDEV is sponsored by OSR
>
>Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
>OSR is HIRING!! See http://www.osr.com/careers
>
>For our schedule of WDF, WDM, debugging and other seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

xxxxx@gmail.com wrote:

I have a requirement to aggregate multiple physical devices with same VID/DeviceID into a single unified controller DO to which clients can get handle, so that clients can have physical-device-agnostic implementation. I have found similar main thread on MSDN forums @ https://social.msdn.microsoft.com/Forums/sqlserver/en-US/41ef66ef-5e7e-4088-b225-b550eef89bb3/kmdf-bus-driver-pcie-child-devices?forum=wdk&prof=required which has been replied by Windows experts like Doron and Don. From the solutions proposed, I can make out that we can solve this requirement by having a separate DO which does not correspond to any particular physical device for this, and this can be a non-PnP CDO (control device object) or a virtual root-enumerated controller device ? both can solve the problem.

Why does it have to be a kernel object at all? It would be easier to
write, easier to debug, and easier to extend if you just wrote a simple
user-mode DLL to wrap all of the ugly details. Make it an
out-of-process COM server if you want to have the actual device objects
owned by a single consumer. I don’t understand what you gain by adding
another device in a separate stack.

Experts, please help me to get clarifications on below questions I have on ‘virtual root-enumerated PnP controller device’ approach I am planning to take to solve this design problem:
? Can I have the same driver expose the root enumerated virtual PnP controller device and also support multiple physical devices, instead of having different drivers for both ?

Yes. It would be easier if all the devices were in the same install
class, that way you could share a single INF.

? Are there any bad WHQL certification implications if we go for such approach ? Basically we are more inclined to have a solution without introducing an extra driver.
? Do we have to run WHQL tests on this virtual root enumerated PnP device also to get driver certified ?

Do you actually need the Windows logo? WHQL doesn’t require that you
test each and every device in an INF. As long as you test one of the
devices in the package, you will pass WHQL.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

Hi Tim, Jan. Thanks for your comments and making this thread alive [:)].

Let me just provide more insight to justify why I am inclined towards this solution. In my case all underlying devices are same type and they provide acceleration services for crypto operations like encryption. The clients using my driver can either be kernel-space clients communicating with my driver using direct-call-interface or user-space clients communicating with me with IOCTL interface (that answers Tim’s question why I do not want a user-space DLL providing aggregation). They just need to call API exposed by my driver like DoEncrypt(key, plaintext, [out]ciphertext) and I want my driver to automatically load-balance such operations across my devices.

Jan, you mentioned about a scenario which u implemented where controller layer also provided facilities like which devices to use beneath, and clients in ur case needing to know when all devices are up. I do not have such requirements. Even if client gets handle to my virtual controller device while physical devices are not up, API calls into my driver will just return failure directly and will start succeeding as soon as one or more physical devices arrive. In these aspects, my requirements seems more inline with the MSDN thread which I mentioned above, where Don/Doron proposed to use control device objects.

[Tim] Do you actually need the Windows logo? WHQL doesn’t require that you
test each and every device in an INF. As long as you test one of the
devices in the package, you will pass WHQL.

I guess once u pass WHQL certification, then u get ‘Certified for Windows’ logo and hence they are same thing. Am i right ? And once u pass that, MS will sign .cat file and u will not see any warning when u try to install ur driver using INF.

6

My problem is I am not able to decide which solution is better amongst below 2 since each has its pros and cons:

  • virtual PnP controller device exposed by my same driver, or
  • non-PnP control device object exposed by my driver

Both solutions have been suggested by Windows experts in 2 threads:
-> one is the MSDN thread which I pointed out
-> I found another related thread on osronline itself:
https://www.osronline.com/showthread.cfm?link=179240

The difference in those threads and the current thread is I am seeking clarifications about many additional questions regarding both approaches, plus I want these controller objects to be in the same driver as for my physical devices.

7

While I’m not one of the lucky members mentioned – you DID choose a particularly nice list, I admit – I’ll tell you that *I* didn’t answer your post because it was too long, asked too many inter-related questions, and was too wide ranging. While I applaud your desire to provide us enough detail to be ABLE to answer your question (and not get the dreaded “please give us more information” reply), your questions are really pretty involved.

While you are likely to get excellent advice here, it is my experience that the quality of the advice you get is inversely proportional to the length of your post and the number of inter-related questions it contains. This is because few people here have the 30 minutes to one hour necessary to read your post carefully, understand it, compose a thoughtful reply, and provide you the answer. And when long posts with multiple inter-related questions ARE thoughtfully answered, the OP rarely can pick the “best” answer from the bunch of replies… because the OP doesn’t know what he doesn’t know.

I apologize if that sounds harsh, I don’t intend it that way. I just want you to know how I’m looking at it, and why I personally didn’t answer you.

I’d be VERY happy to answer your question(s) if you can provided a shorter, more specific, more focused question(s).

Peter
OSR
@OSRDrivers

8

Hi Peter, thanks for your inputs and I will take care of that in future. This is my first post on osronline so will learn by experience. Let me first summarize the precise questions for which I am seeking answers as first priority, along with inputs I have received so far:

(1) Can I have the same driver expose the root enumerated virtual PnP controller
device and also support multiple physical devices, instead of having different
drivers for both ?
[Tim] Yes.

(2) Do you perceive such solution as non-standard with which we can get into any
potential issues in future ?
[No-inputs-yet]. But Jan recommended not to go with it unless there is a good reason to do like that, and I tried to give reasons by explaining my driver use-case. I also clarified why Tim’s recommendation to do aggregation in user-mode DLL is not good for my case.

(3) Are there any bad WHQL certification implications if we go for such approach ? Do we have to run WHQL tests on this virtual root enumerated PnP device also to get driver certified ?
[Tim]: As long as we pass WHQL on one device in package, you will pass WHQL. Hence, from certification perspective no issues seen.

(4) Do we have any drivers in Windows world that follows similar approach which I
outlined here ?
[No-inputs-yet]

(5) Is using a non-PnP CDO instead of virtual PnP controller device, better solution ? My main focus is to have all these in single driver.

(6) Finally if answer to last question is ‘yes’, then I am seeking clarity on 2 issues with non-PnP CDO which can get me in trouble. The scenarios are:

  • potentially not able to unload driver at-all unless reboot
  • my driver ending up with potentially multiple CDOs (current alive CDO and [WdfDeleteObject()
    triggered but not deleted yet] CDOs)

Peter, I hope my above attempt to make my questions clear will be helpful. Actually I have seen that on osronline, some knowledge seekers start with 1-2 basic questions but then thread keeps on extending and extending and even changing its course of focus over the time. I just tried to be clear about all my questions at the beginning. itself. Hope u understand and will help me [:)]

9

I’ve done something similar to what I think you’re describing. That is, I had N devices, but I wanted to expose a SINGLE interface on which to receive Requests. Internally in my driver, I then routed the Requests to the desired device.

I did this by exposing a Control Device Object. I’ve got to tell you: It was a REAL pain in the ass. You’ve got to create the CDO when the first device is detected (so, in your EvtDriverDeviceAdd or someplace similar), and you’ve got to delete the CDO when the last device goes away (so, in the Destroy callback for your last WDFDEVICE). This just wasn’t very smooth. You have to deal with the counting, the locking, and any potential errors. In short, I got it to work, but it wasn’t much fun. Don’t forget to purge the Queue for the CDO before deleting it :wink:

I’m not saying it’s impossible, or “really really hard” or not supported. It’s supported.

I probably would have been better off creating a bus driver that exposes a RAW PDO and using THAT in the same role that I used the Control Device Object. You can create a Device Interface that way, AND many things turn out a whole lot easier.

Are there existing devices in the system that work this way? I can’t think of any off the top of my head. But that doesn’t mean this isn’t a good approach.

You COULD create a separate “collection” driver (PnP software-only driver), that creates a single Device and that people open to send their I/O. That allows you the OPTION of using it or not. That might be simpler, in some ways. You just open the underlying devices as Remote I/O Targets and you’re good to go. The problem with this approach is that unless you’re clever, the underlying device objects can be opened separately. So, while you WANT all Requests to go to your “collection” driver, could a user app not bypass it and directly open the underlying devices? You’d need to build a way into the underlying driver to detect this.

Either way will work. Neither is a terrible idea.

Peter
OSR
@OSRDrivers

10

On 16-Oct-2015 19:09, xxxxx@osr.com wrote:
…

I probably would have been better off creating a bus driver that exposes a RAW PDO and using THAT in the same role that I used the Control Device Object. You can create a Device Interface that way, AND many things turn out a whole lot easier.
…

You COULD create a separate “collection” driver (PnP software-only driver), that creates a single Device and that people open to send their I/O. That allows you the OPTION of using it or not. That might be simpler, in some ways.

How about this variant:
One driver is installed on all the physical devices (by their physical
hw id) and additional root enumerated device, created manually (by
devcon install) ?

With this design, the single driver will have all the state and PnP
notification for all physical devices. Then, define an devinterface and
enable it only on the root-enumerated instance.
The control (root-enumerated) device won’t go away by itself, so the
driver will stay pinned in memory.
But you still can remove it by disabling the root-enumerated device.

– pa

11

My current understanding is on Server 2016, you will not be able to even load a driver (except in test mode) that has not passed WHQL certification. As your device almost certainly doesn’t fit any of the defined device types, there will be no way to even test for certification. It may not matter what driver architecture you use, as the issue is: can unusual device types with custom interfaces pass the WHQL certification needed to get the signature needed to load on Server 2016. There has been in the past a set of WHQL tests called “unclassified”, and by passing them you could get the digital signature needed to load. Passing the unclassified tests was not the same as being “WHQL certified”. A driver with an unclassified signature can’t use the Microsoft certified Logo, but at least could be loaded without explicitly installing it’s signing key. The ability to install your own signing key is removed from Windows 10, and all indications are Server 2016.

I think the question for Microsoft is: can an unusual device still get the equivalent of an unclassified digital signature on Server 2016? If the answer is no, then everybody working on unusual devices will apparently be supporting Linux and not Windows server in the future.

Offhand, assuming you’re targeting server systems, which seems likely for a crypto accelerator, you may have a serious problem.

Jan

On 10/16/15, 7:05 AM, “xxxxx@lists.osr.com on behalf of xxxxx@gmail.com” wrote:

>(3) Are there any bad WHQL certification implications if we go for such approach ? Do we have to run WHQL tests on this virtual root enumerated PnP device also to get driver certified ?
>[Tim]: As long as we pass WHQL on one device in package, you will pass WHQL. Hence, from certification perspective no issues seen.
>

12

Thanks Peter and ‘PavelA’ for your comments.

[Peter] You COULD create a separate “collection” driver (PnP software-only driver), that
creates a single Device and that people open to send their I/O.

That’s what one of my proposed solution is, instead of use non-PnP CDO. Just difference is that I would like it to be hosted in the same driver as my driver for physical devices. That’s exactly what [PavelA] pointed out.

[Pavel A] How about this variant: One driver is installed on all the physical devices (by their physical hw id) and additional root enumerated device, created manually (by devcon install) ?

That’s what one of my proposed is, for which I am seeking answers from experts out here [my questions (1) - (5)]

[Jan] As your device almost certainly doesn?t fit any of the defined device types, there will
be no way to even test for certification.

I am proposing to have this virtual PnP device in the same driver which support my physical devices. And as per the inputs from Tim, as long as we pass WHQL on one device in package, we will pass WHQL. Also, define will have same installClass and integrated into same INF file (as recommended by Tim also).

13

I can’t imagine any other way this could work. Seriously. How could there be a specific logo program for every device that could be in a server? It’s simply not possible. And I can’t imagine Microsoft has any interest at all in forcing these devices OUT of Windows Server systems.

As far as the OP is concerned, maybe his DEVICE fits into a nice neat category. if that’s the case, then he’s all set as long as his driver passes the tests for the category.

Peter
OSR
@OSRDrivers

14

On 16-Oct-2015 23:50, xxxxx@gmail.com wrote:

> [Pavel A] How about this variant: One driver is installed on all the physical devices (by their physical hw id) and additional root enumerated device, created manually (by devcon install) ?

That’s what one of my proposed is, for which I am seeking answers from experts out here [my questions (1) - (5)]

Ah, yes. You’ve written this in your post in the MSDN WDK forum. Having
a discussion in only one place usually helps keep it more focused.

  • pa
15

I would really aggregate in user mode.

This is the way Raw Input Thread does for keyboard/mouse, and the way sound stack works.

Issues with the need of some “aggregation device” in kernel mode, its PnP parent and PnP state etc. seems to be really an overkill.

If you need to provide hardware-agnostic API - provide it from a user-mode DLL.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hi Windows Driver Experts,
>
> I have a requirement to aggregate multiple physical devices with same VID/DeviceID into a single unified controller DO to which clients can get handle, so that clients can have physical-device-agnostic implementation. I have found similar main thread on MSDN forums @ https://social.msdn.microsoft.com/Forums/sqlserver/en-US/41ef66ef-5e7e-4088-b225-b550eef89bb3/kmdf-bus-driver-pcie-child-devices?forum=wdk&prof=required which has been replied by Windows experts like Doron and Don. From the solutions proposed, I can make out that we can solve this requirement by having a separate DO which does not correspond to any particular physical device for this, and this can be a non-PnP CDO (control device object) or a virtual root-enumerated controller device ? both can solve the problem. I am more keen to use virtual root-enumerated PnP controller device because of following benefits which cannot be provided by non-PnP CDO:
> ? We can support device interfaces on PnP controller device and hence its easy for clients to get handle to the controller device by just waiting for GUID_DEVICE_INTERFACE_ARRIVAL notification.
> ? We have several clients running on top of base PnP driver, and we still would like individual physical devices to be disabled/enabled. So it?s very likely that we have active references to controller device taken by many clients, and hence controller device will not be able to delete when all physical devices are disabled. With non-PnP CDO, we will no longer be able to unload such driver in such scenarios. But with PnP CDO, we can still unload driver when we remove root-enumerated device from PnP manager.
>
> Experts, please help me to get clarifications on below questions I have on ‘virtual root-enumerated PnP controller device’ approach I am planning to take to solve this design problem:
> ? Can I have the same driver expose the root enumerated virtual PnP controller device and also support multiple physical devices, instead of having different drivers for both ?
> ? Do you perceive such solution as non-standard with which we can get into any potential issues in future ?
> ? Are there any bad WHQL certification implications if we go for such approach ? Basically we are more inclined to have a solution without introducing an extra driver.
> ? Do we have to run WHQL tests on this virtual root enumerated PnP device also to get driver certified ?
> ? Do we have any drivers in Windows world that follows similar approach which I outlined here ?
>
> I do agree that using non-PnP controller device have below benefits:
> ? No need to make extra efforts in installer/uninstaller and driver INF to add support for virtual PnP controller device.
> ? Virtual PnP device will only load driver at system startup even if there are no active/enabled physical devices related to the hardware. But with non-PnP CDO, driver will only load on detection of physical device and CDO will be created on 1st EvtDeviceAdd.
> But I feel that the disadvantages outlined in the beginning overweighs the benefits. Especially I am not able to understand how the below user-case will work when using non-PnP CDO. Can experts here clarify on the below use-case also if we use a non-PnP CDO ?
> ? 2 physical devices detected, PnP loads the driver and call EvtDeviceAdd for each. In first EvtDeviceAdd, CDO also created and symbolic link created over it (for clients to use).
> ? Several clients got handle to the CDO and started using the device by issuing IOCTLs to that.
> ? Both devices get disabled one by one. At last device?s removal handling, WdfObjectDelete() is called on CDO to delete it but it will not get deleted because clients have active references to it. As a result, driver will also not get unloaded and cannot be unloaded again unless another physical device PnP removal gets triggered somehow.
> ? A physical device comes up again. I guess we are supposed to create a new CDO since we already called WdfObjectDelete() on old CDO, right ? Also if we do that, then does that mean that existing clients will keep on issuing IOCTLs to older CDO whereas new clients will get newly created CDO ? Also, does that mean that driver have to track the IO queue of the older [WdfDeleteObject() triggerred but not deleted yet] CDOs and current alive CDO ?
>
>
>

16

On 17-Oct-2015 01:09, Maxim S. Shatskih wrote:

If you need to provide hardware-agnostic API - provide it from a user-mode DLL.

Even if it has kernel-mode clients?

  • pa
17

I could easily imagine that Microsoft could decide non-standard devices cause 90% of the server OS support and stability problems, and only increases Microsoft sales 5%, so a valid business decision would be to write off that 5%. This also would not mean Microsoft OSs can’t run workloads on non-standard hardware, it just means they might have to run as a VM on non-standard hardware. If over time, that non-standard hardware became popular, and became more standardized, Microsoft could then add certifications tests.

From what I’ve heard, Server 2016 driver MUST pass the equivalent of WHQL certification, and in the past passing unclassified tests did not get your certification, which to me sounds like the end of devices on Server 2016 that can’t pass at least one category of certification testing.

The question seems to be: how much would it really impact Microsoft sales if ALL non-standard hardware were exclude from running under the server OS. It also would be technically a trivial matter for them to have two servers SKUs, the guaranteed stable SKU that ONLY works with certified HW, and the use at your own risk SKU that lets you run whatever by installing your own code signing cert. Each might have different support terms, and target very different classes of customers.

It seems like there is the variant of some device that can pass WHQL certification tests for some function, but also has EXTRA interfaces for things that have no certification tests. Due to the certified feature, you could get the driver signed and loaded, and then access your unique features. I’m working on drivers for a device like this right now (resembles a high speed non-Ethernet NIC), and have considered how to pass WHQL certification and still expose unique hardware features that some customers might find really useful.

Jan

On 10/16/15, 2:04 PM, “xxxxx@lists.osr.com on behalf of xxxxx@osr.com” wrote:

>


>
>I can’t imagine any other way this could work. Seriously. How could there be a specific logo program for every device that could be in a server? It’s simply not possible. And I can’t imagine Microsoft has any interest at all in forcing these devices OUT of Windows Server systems.
>
>As far as the OP is concerned, maybe his DEVICE fits into a nice neat category. if that’s the case, then he’s all set as long as his driver passes the tests for the category.
>
>Peter
>OSR
>@OSRDrivers
>

18

> [PavelA]: Ah, yes. You’ve written this in your post in the MSDN WDK forum. Having
a discussion in only one place usually helps keep it more focused.

Nice catch, and sorry if I am not supposed to do that. Actually that MSDN forum thread is the same which I pointed above and I posted some of my above questions there first. But then thought it would be nice to post here also because I have seen Don/Doron to be active here. BTW, I manage to get some input from Don Burn on that forum which I feel useful to share here also:

[Don Burn]: You should be able to support both devices with a single driver. You do need to have smarts to handle the fact that physical devices have resources (registers, ports, interrupts) and virtual devices do not, but within those constraints you can do it.

[PavelA/MaximS]: Pavel: Even if it has kernel-mode clients?

Yes, correct.

19

> [Peter]: As far as the OP is concerned, maybe his DEVICE fits into a nice neat category.
if that’s the case, then he’s all set as long as his driver passes the tests for the category.

[Jan]: It seems like this is the variant of some device that can pass WHQL certification tests for some function, but also has EXTRA interfaces for things that have no certification tests. Due to the certified feature, you could get the driver signed and loaded, and then access your unique features. I?m working on drivers for a device like this right now (resembles a high speed non-Ethernet NIC), and have considered how to pass WHQL certification and still expose unique hardware features that some customers might find really useful.

Hi Peter/Jan, you are right above. My physical devices belongs to a well defined category and not ‘unknown category’. Also, my physical devices and this virtual device, in INF, will use the same device class (though I am planning to just hide this virtual PnP device from devmgr). As per inputs by Tim, I can get my driver pass WHQL for my physical device and do not need any tests for virtual PnP device. BTW, my devices target server systems.

Peter/Jan, with above clarifications, does my proposed approach to expose ‘physical devices’ and ‘a single virtual PnP unified device’ by my same driver looks ok to you ?

Summarizing the inputs I have received till now

  • Tim, PavelA, and Don Burn seems to have given green flag to the approach.
  • Peter has given green flag to go with non-PnP device-object within same driver to do aggregation. But not sure about his final verdict on using vitual-PnP QAT device.
20

> The question seems to be: how much would it really impact Microsoft sales if ALL non-standard

hardware were exclude from running under the server OS.

What about 3rd party kernel mode software, which can be hardware-less?

What about some really new HW (say: a new generation of Infiniband or Converged Ethernet), for which WHQL tests are not there yet? Won’t people switch to ESX Server or Linux to run this HW?

Also IIRC the Device Guard policy is configurable, am I wrong?

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com