NDIS IM driver in the paging path

OSR_Community_User · September 30, 2010, 11:56am

Does anybody know if it’s possible to have an NDIS IM driver in the paging
path? I don’t really see how you would route the special file notification
IRP’s or tell the OS what the power relations are between virtual and
physical nic’s? The context is W2K8R2 systems that are iSCSI booted.

Jan

anton_bassov · September 30, 2010, 9:59pm

> Does anybody know if it’s possible to have an NDIS IM driver in the paging path?

Assuming that your NDIS IM registers a control device that allows it to take requests from non-NDIS components I don’t see any reason why the whole thing is impossible - IIRC, there is nothing that disallows drivers in either FSD or storage stacks to send requests to drivers in different stacks.

IIRC, when it comes to the paging IO path, the only requirements are, first, not to cause nested page faults in the paging IO path to pagefile ( nested page fault in the paging IO path to the mapped file is OK) while processing MJ_READ requests, and, second, not to go blocking while processing asynchronous IRPs (in practical terms this part applies only to MJ_WRITE ones that get submitted by mapped and modified page writer threads)

As long as you ensure that you don’t cause a nested page fault in your IM in the paging IO path to pagefile I don’t see anything that stands in your way …

Anton Bassov

OSR_Community_User · October 1, 2010, 1:31am

Hi Anton,

I’ll have to look at NDIS control devices some more, but don’t offhand see
how they help. I thought NDIS control objects are just free standing legacy
device objects.

I assume the PnP special file notification IRP sent to an NDIS IM virtual
NIC will be something like:

FSD->disk->iSCSI initiator->TCP/IP->IM upper edge virtual NIC (which is root
enumerated)->root enum pdo

This gives me the sense that IM drivers may not work in the paging path
normally, as the special file IRP won’t get correctly forwarded to the
physical NIC.

Somehow the special file notification needs to get routed from the IM
virtual NIC to the physical NIC, as in:

FSD->disk->iSCSI initiator->TCP/IP->IM upper edge virtual NIC (root
enumerated)->physical NIC->PCI bus

Since the NDIS wrapper handles the PnP IRP for NIC’s, I don’t see how I
could get the special file requests redirected from the virtual NIC to the
physical NIC. It’s not so clear what should happen to the protocol IM lower
edge device either. I assume higher levels would send the special file IRP
to the virtual NIC device, not a control device, although perhaps I should
spend a while doing some IRP tracing on an iSCSI system. I suppose I could
also have a lower filter below the root enumerated IM virtual NIC, which was
responsible for special file notification IRP forwarding.

One though is it would have to be implemented as a WDM virtual NIC and a
virtual bus, like:

FSD->disk->iSCSI initiator->TCP/IP->WDM/KMDF virtual NIC (enumerated on a
virtual bus)->virtual bus PDO->virtual bus FDO (protocol device?)->physical
NIC->PCI

The reason for the virtual bus is it can intercept the special file
notifications at the PDO and forward them to the correct physical NIC stack.

Something has to happen with the power relations too, as things will not be
in a nice clean PnP hierarchy which makes a nice clean power hierarchy.

Avoiding nested page faults seems doable. Paging path drivers are also
supposed to always make forward progress, even under out of memory
conditions, which seems like could be handled by careful preallocation of
resources and perhaps throttling of packets under low memory.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-426491-
xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, September 30, 2010 7:02 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NDIS IM driver in the paging path

> Does anybody know if it’s possible to have an NDIS IM driver in the
paging
path?

Assuming that your NDIS IM registers a control device that allows it to
take
requests from non-NDIS components I don’t see any reason why the whole
thing is impossible - IIRC, there is nothing that disallows drivers in
either FSD
or storage stacks to send requests to drivers in different stacks.

IIRC, when it comes to the paging IO path, the only requirements are,
first,
not to cause nested page faults in the paging IO path to pagefile (
nested
page fault in the paging IO path to the mapped file is OK) while
processing
MJ_READ requests, and, second, not to go blocking while processing
asynchronous IRPs (in practical terms this part applies only to MJ_WRITE
ones
that get submitted by mapped and modified page writer threads)

As long as you ensure that you don’t cause a nested page fault in your IM
in
the paging IO path to pagefile I don’t see anything that stands in your
way …

Anton Bassov

NTDEV is sponsored by OSR

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

anton_bassov · October 1, 2010, 2:43am

> I’ll have to look at NDIS control devices some more, but don’t offhand see how they help. I thought

NDIS control objects are just free standing legacy device objects.

This is exactly what they are, and registering such DO allows you to send a request to miniport driver that is otherwise not accessible by anyone, apart from NDIS library, which communicates with it via callbacks, rather than IRPs. In fact, this is the sole purpose of these DOs - if you don’t register such DO you will be just unable to access miniport from non-NDIS driver because NIC miniports never deal with IRPs…

FSD->disk->iSCSI initiator->TCP/IP->IM upper edge virtual NIC (which is root enumerated)->root enum pdo

TCP/IP->IM upper edge virtual NIC communication is not going to be via IRP, is it…

One though is it would have to be implemented as a WDM virtual NIC and a virtual bus, like:
FSD->disk->iSCSI initiator->TCP/IP->WDM/KMDF virtual NIC (enumerated on a virtual bus)->virtual bus >PDO->virtual bus FDO (protocol device?)->physical NIC->PCI

Just a question - why do you think you need a virtual bus???

Anton Bassov

David_R_Cattley · October 1, 2010, 11:53am

Jan,

Have you considered inserting a PnP Filter into the IM driver Miniport
Device Stack so that your filter could reflect the IRP into the stack of the
physical adapter?

I have not tried this for the purpose of diverting the paging-path
notifications ‘around’ and IM driver but I have done it for other reasons to
get involved in the PnP IRP dialog for an NDIS IM Driver Miniport.

Alternatively, have you considered just capturing back the dispatch
routine(s) you need to be involved in after registering with the NDIS
wrapper? That might actually be less gobledy-gook but at least a PnP
filter will play nicely with NDIS.

I don’t quite know what the control device gets you either.

As for the re-casting the NDIS IM driver support (where NDIS ‘helps’ with
the effective child device activation) into a more classic PnP parent/child
heirachy you sort of run into doing some equally crazy stuff like:

Create PnP upper filter on target NIC which is also your ‘protocol’.
Enumerate child DO(s) which become your Upper Edge Miniport Device(s).
Since now your FiDO in the target device stack is the ‘bus’ object, you
get the IRPs paging notification.
The NDIS Miniport upper edge is just an NDIS-KMDF or NDIS-WDM style and
you have to re-plumb the UpperMinipor<->LowerProtocol relationship manually
by doing some (typically) private IRPs or better QueryInterface from the
NDIS Miniport ‘down the stack’ to your FiDO PDO.

I would say it is all doable but you now have to duplicate what NDIS was
doing for you and that is turning the ‘binding state’ on the lower edge into
something that effects the PnP lifetime of the upper edge Miniport PDO(s).

It is important to preserve the IM driver behavior that ‘unbinding’ (not
just stopping) the lower edge causes the Upper Edge to unbind.

If it were my science project, I think I would try the skullduggery of the
filter driver first to see if I could avoid re-doing all of what NDIS does
in regards to Upper/Lower management.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Friday, October 01, 2010 1:31 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS IM driver in the paging path