bus enumartion from filter driver

Hi all

I am writing filter driver for pci bridge the filter will be upper filter for the PCI.sys driver.
My driver is KMDF driver.
I want to intercept all PnP IRPs that go down to the pci.sys driver.
How can I do that using WDF driver?

My goal is to simulate add/remove (eject) of devices from that bridge (while the devices still connect) My filter will get an IOCTL to remove child and in turn will change the child list and notify the PnP of child removal.

If I understand correctly I need to get the child list of my underlying pci.sys driver and change it

How Can I get the underlying child list of the pci.sys and change it (while notifying the PnP manager)

Thanks
Yossi

The list is obtained by filtering IRP_MN_QUERY_DEVICE_RELATIONS and
examining the output from the BusRelations subtype of this request.If you
want to provoke PnP do do a re-enumeration use *IoInvalidateDeviceRelations.
*

On Mon, Jun 16, 2008 at 5:48 AM, Yossi Leybovich <
xxxxx@wilocity.com> wrote:

Hi all

I am writing filter driver for pci bridge the filter will be upper filter
for the PCI.sys driver.
My driver is KMDF driver.
I want to intercept all PnP IRPs that go down to the pci.sys driver.
How can I do that using WDF driver?

My goal is to simulate add/remove (eject) of devices from that bridge
(while the devices still connect) My filter will get an IOCTL to remove
child and in turn will change the child list and notify the PnP of child
removal.

If I understand correctly I need to get the child list of my underlying
pci.sys driver and change it

How Can I get the underlying child list of the pci.sys and change it (while
notifying the PnP manager)

Thanks
Yossi


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


Mark Roddy

Yossi, you cannot make PDOs that you do not own disappear. If PCI thinks that they have been reported as present and then you report them as missing, there is a state change that PCI will miss that is very important. PNP will send a surprise remove + remove and expect PCI to delete the PDO on the remove (b/c it was reported missing). PCI will not know this and will keep the PDO around, violating the pnp state rules and will blow up soon there after.

Let me reemphasize this: you are going down a path that is pure hackery that will not get you want you want, even for test purposes this is a very very bad idea.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, June 16, 2008 3:19 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] bus enumartion from filter driver

The list is obtained by filtering IRP_MN_QUERY_DEVICE_RELATIONS and examining the output from the BusRelations subtype of this request.If you want to provoke PnP do do a re-enumeration use IoInvalidateDeviceRelations.
On Mon, Jun 16, 2008 at 5:48 AM, Yossi Leybovich > wrote:

Hi all

I am writing filter driver for pci bridge the filter will be upper filter for the PCI.sys driver.
My driver is KMDF driver.
I want to intercept all PnP IRPs that go down to the pci.sys driver.
How can I do that using WDF driver?

My goal is to simulate add/remove (eject) of devices from that bridge (while the devices still connect) My filter will get an IOCTL to remove child and in turn will change the child list and notify the PnP of child removal.

If I understand correctly I need to get the child list of my underlying pci.sys driver and change it

How Can I get the underlying child list of the pci.sys and change it (while notifying the PnP manager)

Thanks
Yossi


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


Mark Roddy — 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

Thanks

Still how can I intercept PnP IRPs of my lower driver in KMDF driver ?
Cant I use standard KMDF function to retrieve the child list of my lower driver?

Thanks
Yossi

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, June 16, 2008 1:19 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] bus enumartion from filter driver

The list is obtained by filtering IRP_MN_QUERY_DEVICE_RELATIONS and examining the output from the BusRelations subtype of this request.If you want to provoke PnP do do a re-enumeration use IoInvalidateDeviceRelations.
On Mon, Jun 16, 2008 at 5:48 AM, Yossi Leybovich > wrote:

Hi all

I am writing filter driver for pci bridge the filter will be upper filter for the PCI.sys driver.
My driver is KMDF driver.
I want to intercept all PnP IRPs that go down to the pci.sys driver.
How can I do that using WDF driver?

My goal is to simulate add/remove (eject) of devices from that bridge (while the devices still connect) My filter will get an IOCTL to remove child and in turn will change the child list and notify the PnP of child removal.

If I understand correctly I need to get the child list of my underlying pci.sys driver and change it

How Can I get the underlying child list of the pci.sys and change it (while notifying the PnP manager)

Thanks
Yossi


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


Mark Roddy — 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

Set a WDM preprocessing routine (WdfDeviceInitAssignWdmIrpPreprocessCallback) to intercept the pnp irps. There is no such thing as “the child list” of your lower driver,a WDFCHILDLIST is a KMDF abstraction that is tied to a particular WDFDEVICE and is not sharable.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Yossi Leybovich
Sent: Monday, June 16, 2008 11:34 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

Thanks

Still how can I intercept PnP IRPs of my lower driver in KMDF driver ?
Cant I use standard KMDF function to retrieve the child list of my lower driver?

Thanks
Yossi

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, June 16, 2008 1:19 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] bus enumartion from filter driver

The list is obtained by filtering IRP_MN_QUERY_DEVICE_RELATIONS and examining the output from the BusRelations subtype of this request.If you want to provoke PnP do do a re-enumeration use IoInvalidateDeviceRelations.
On Mon, Jun 16, 2008 at 5:48 AM, Yossi Leybovich > wrote:

Hi all

I am writing filter driver for pci bridge the filter will be upper filter for the PCI.sys driver.
My driver is KMDF driver.
I want to intercept all PnP IRPs that go down to the pci.sys driver.
How can I do that using WDF driver?

My goal is to simulate add/remove (eject) of devices from that bridge (while the devices still connect) My filter will get an IOCTL to remove child and in turn will change the child list and notify the PnP of child removal.

If I understand correctly I need to get the child list of my underlying pci.sys driver and change it

How Can I get the underlying child list of the pci.sys and change it (while notifying the PnP manager)

Thanks
Yossi


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


Mark Roddy — 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


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

HI Doron

My bridge want to fully support hot plug/unplug of devices sits on the bus under it.
We found that many PCI devices does not support hot plug/unplug specially display devices .
But we do see that most of the devices do support gracefully removal .
I want to get interrupt from my bridge when it sense that there is going to be surprise removal (we have an algorithm to determine that in our system ) and notify the PnP so it will initiate graceful removal.

My solution right now is to have application in user space that will wait for my driver event to disable/enable the devices under my bridge.
When my filter get interrupt from the bridge it set the event and the application disable/enable the devices.
And this works fine (as u can remove/disable device even if it physically still there)

Is there is any way to that in KMDF? Without using use space application.
How can I initiate graceful removal from within kernel , so the PnP will sends query removal and removal to the devices? And update pci.sys , so pci.sys will delete the PDOs.
And in the general case can filter driver above bus driver can have any control on the device list that the bus report to the PnP ?
I can see various cases where vendors will want to report/not report devices they created to the PnP.

One more question :
How can I intercept PnP IRPs that directed to my lower driver (pci.sys) using KMDF.

Thanks
Yossi

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 16, 2008 9:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

Yossi, you cannot make PDOs that you do not own disappear. If PCI thinks that they have been reported as present and then you report them as missing, there is a state change that PCI will miss that is very important. PNP will send a surprise remove + remove and expect PCI to delete the PDO on the remove (b/c it was reported missing). PCI will not know this and will keep the PDO around, violating the pnp state rules and will blow up soon there after.

Let me reemphasize this: you are going down a path that is pure hackery that will not get you want you want, even for test purposes this is a very very bad idea.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, June 16, 2008 3:19 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] bus enumartion from filter driver

The list is obtained by filtering IRP_MN_QUERY_DEVICE_RELATIONS and examining the output from the BusRelations subtype of this request.If you want to provoke PnP do do a re-enumeration use IoInvalidateDeviceRelations.
On Mon, Jun 16, 2008 at 5:48 AM, Yossi Leybovich > wrote:

Hi all

I am writing filter driver for pci bridge the filter will be upper filter for the PCI.sys driver.
My driver is KMDF driver.
I want to intercept all PnP IRPs that go down to the pci.sys driver.
How can I do that using WDF driver?

My goal is to simulate add/remove (eject) of devices from that bridge (while the devices still connect) My filter will get an IOCTL to remove child and in turn will change the child list and notify the PnP of child removal.

If I understand correctly I need to get the child list of my underlying pci.sys driver and change it

How Can I get the underlying child list of the pci.sys and change it (while notifying the PnP manager)

Thanks
Yossi


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


Mark Roddy — 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


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

You cannot initiate a graceful remove in kernel, that is not exposed to WDM so KMDF cannot do anything magical. That means you must have the UM app do it based off of a notification from your driver

And update pci.sys , so pci.sys will delete the PDOs.
Do not think there is a way to do this unless you somehow make pci think it is a pccard slot

And in the general case can filter driver above bus driver can have any control on the device list that the bus report to the PnP ?
Not really, no. if you do intercept QDR(BusRelations) you have to fully simulate the pnp manager’s behavior and there are many aspects of that behavior that you cannot fake out b/c you do not have the interfaces to the rest of the system that a pnp state change uses, esp resource arbitration interfaces and the channel to the user mode pnp manager.

How can I intercept PnP IRPs that directed to my lower driver (pci.sys) using KMDF.
I do not understand the question. You have a wdm preprocess routine in kmdf which lets you see all incoming pnp irps. If you mean all pnp irps that KMDF sends down the stack, no there is no hook for that, but there is no real need to hook any of these as far as I can see (you can always post process in a completion routine you set in your preprocess routine)

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Yossi Leybovich
Sent: Tuesday, June 17, 2008 1:49 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

HI Doron

My bridge want to fully support hot plug/unplug of devices sits on the bus under it.
We found that many PCI devices does not support hot plug/unplug specially display devices .
But we do see that most of the devices do support gracefully removal .
I want to get interrupt from my bridge when it sense that there is going to be surprise removal (we have an algorithm to determine that in our system ) and notify the PnP so it will initiate graceful removal.

My solution right now is to have application in user space that will wait for my driver event to disable/enable the devices under my bridge.
When my filter get interrupt from the bridge it set the event and the application disable/enable the devices.
And this works fine (as u can remove/disable device even if it physically still there)

Is there is any way to that in KMDF? Without using use space application.
How can I initiate graceful removal from within kernel , so the PnP will sends query removal and removal to the devices? And update pci.sys , so pci.sys will delete the PDOs.
And in the general case can filter driver above bus driver can have any control on the device list that the bus report to the PnP ?
I can see various cases where vendors will want to report/not report devices they created to the PnP.

One more question :
How can I intercept PnP IRPs that directed to my lower driver (pci.sys) using KMDF.

Thanks
Yossi

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 16, 2008 9:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

Yossi, you cannot make PDOs that you do not own disappear. If PCI thinks that they have been reported as present and then you report them as missing, there is a state change that PCI will miss that is very important. PNP will send a surprise remove + remove and expect PCI to delete the PDO on the remove (b/c it was reported missing). PCI will not know this and will keep the PDO around, violating the pnp state rules and will blow up soon there after.

Let me reemphasize this: you are going down a path that is pure hackery that will not get you want you want, even for test purposes this is a very very bad idea.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, June 16, 2008 3:19 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] bus enumartion from filter driver

The list is obtained by filtering IRP_MN_QUERY_DEVICE_RELATIONS and examining the output from the BusRelations subtype of this request.If you want to provoke PnP do do a re-enumeration use IoInvalidateDeviceRelations.
On Mon, Jun 16, 2008 at 5:48 AM, Yossi Leybovich > wrote:

Hi all

I am writing filter driver for pci bridge the filter will be upper filter for the PCI.sys driver.
My driver is KMDF driver.
I want to intercept all PnP IRPs that go down to the pci.sys driver.
How can I do that using WDF driver?

My goal is to simulate add/remove (eject) of devices from that bridge (while the devices still connect) My filter will get an IOCTL to remove child and in turn will change the child list and notify the PnP of child removal.

If I understand correctly I need to get the child list of my underlying pci.sys driver and change it

How Can I get the underlying child list of the pci.sys and change it (while notifying the PnP manager)

Thanks
Yossi


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


Mark Roddy — 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


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


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

The OP is facing a problem that we have considerable experience with at
Stratus Technologies. His estimation that many pci device drivers will not
behave well under suprise removal is correct, many will hang or crash the
system. His solution is difficult to implement, as you point out, and is
going in the wrong direction. Most of the pci drivers we have put through
our surprise removal torture chamber (our systems have hot removable
customer replaceable PCI busses that we stress test the heck out of) fail,
and fail because they are not coded with any awareness that the hardware
they communicate with can disappear. The hardware disappears regardless of
what the OP (or Stratus) does with PnP state for the device. Surprise
Removal state is a result of detecting vanished hardware, putting off the
transition to Surprise Removal state does not somehow defer the removal of
the hardware, and consequently the faulty pci device drivers will fail just
as much after the OP manages to defer the transition as they did before he
made these useless changes.

On the other hand, the OP could and in fact must, convince the pci bus
driver to do a re-enumeration everytime the OP’s software detects a device
removal, as pci.sys only supports the hot plug interrupt mechanism (as in
pccards) so it will be unaware of any other hot removal. That is where
IoInvalidateDeviceRelations comes in. Once again, this will not fix the
faulty device drivers, it will simply convince pci.sys to initiate PnP state
transitions.

What is the poor OP to do? Unfortunately the only answer is to work with the
vendors to convince them to fix their drivers. Stratus gave a presentation
on ‘Driver Hardening’ at WinHec a few years ago that outlined the steps
required to write a driver that can handle losing its hardware. It actually
isn’t rocket science. Of course, unless the OP has some leverage with every
manufacturer out there who has devices that can be plugged into the OP’s
system, this is not a good answer.

On Tue, Jun 17, 2008 at 5:02 AM, Doron Holan
wrote:

> You cannot initiate a graceful remove in kernel, that is not exposed to
> WDM so KMDF cannot do anything magical. That means you must have the UM app
> do it based off of a notification from your driver
>
>
>
> >And update pci.sys , so pci.sys will delete the PDOs.
>
> Do not think there is a way to do this unless you somehow make pci think it
> is a pccard slot
>
>
>
> > And in the general case can filter driver above bus driver can have any
> control on the device list that the bus report to the PnP ?
>
> Not really, no. if you do intercept QDR(BusRelations) you have to fully
> simulate the pnp manager’s behavior and there are many aspects of that
> behavior that you cannot fake out b/c you do not have the interfaces to the
> rest of the system that a pnp state change uses, esp resource arbitration
> interfaces and the channel to the user mode pnp manager.
>
>
>
> > How can I intercept PnP IRPs that directed to my lower driver (pci.sys)
> using KMDF.
>
> I do not understand the question. You have a wdm preprocess routine in
> kmdf which lets you see all incoming pnp irps. If you mean all pnp irps that
> KMDF sends down the stack, no there is no hook for that, but there is no
> real need to hook any of these as far as I can see (you can always post
> process in a completion routine you set in your preprocess routine)
>
>
>
> d
>
>
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *Yossi Leybovich
> Sent: Tuesday, June 17, 2008 1:49 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] bus enumartion from filter driver
>
>
>
> HI Doron
>
>
>
> My bridge want to fully support hot plug/unplug of devices sits on the bus
> under it.
>
> We found that many PCI devices does not support hot plug/unplug specially
> display devices .
>
> But we do see that most of the devices do support gracefully removal .
>
> I want to get interrupt from my bridge when it sense that there is going to
> be surprise removal (we have an algorithm to determine that in our system )
> and notify the PnP so it will initiate graceful removal.
>
>
>
> My solution right now is to have application in user space that will wait
> for my driver event to disable/enable the devices under my bridge.
>
> When my filter get interrupt from the bridge it set the event and the
> application disable/enable the devices.
>
> And this works fine (as u can remove/disable device even if it physically
> still there)
>
>
>
>
>
> Is there is any way to that in KMDF? Without using use space application.
>
> How can I initiate graceful removal from within kernel , so the PnP will
> sends query removal and removal to the devices? And update pci.sys , so
> pci.sys will delete the PDOs.
>
> And in the general case can filter driver above bus driver can have any
> control on the device list that the bus report to the PnP ?
>
> I can see various cases where vendors will want to report/not report
> devices they created to the PnP.
>
>
>
> One more question :
>
> How can I intercept PnP IRPs that directed to my lower driver (pci.sys)
> using KMDF.
>
>
>
> Thanks
>
> Yossi
>
>
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *Doron Holan
> Sent: Monday, June 16, 2008 9:03 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] bus enumartion from filter driver
>
>
>
> Yossi, you cannot make PDOs that you do not own disappear. If PCI thinks
> that they have been reported as present and then you report them as missing,
> there is a state change that PCI will miss that is very important. PNP will
> send a surprise remove + remove and expect PCI to delete the PDO on the
> remove (b/c it was reported missing). PCI will not know this and will keep
> the PDO around, violating the pnp state rules and will blow up soon there
> after.
>
>
>
> Let me reemphasize this: you are going down a path that is pure hackery
> that will not get you want you want, even for test purposes this is a very
> very bad idea.
>
>
>
> d
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *Mark Roddy
> Sent: Monday, June 16, 2008 3:19 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] bus enumartion from filter driver
>
>
>
> The list is obtained by filtering IRP_MN_QUERY_DEVICE_RELATIONS and
> examining the output from the BusRelations subtype of this request.If you
> want to provoke PnP do do a re-enumeration use
> IoInvalidateDeviceRelations.

>
> On Mon, Jun 16, 2008 at 5:48 AM, Yossi Leybovich <
> xxxxx@wilocity.com> wrote:
>
>
> Hi all
>
> I am writing filter driver for pci bridge the filter will be upper filter
> for the PCI.sys driver.
> My driver is KMDF driver.
> I want to intercept all PnP IRPs that go down to the pci.sys driver.
> How can I do that using WDF driver?
>
> My goal is to simulate add/remove (eject) of devices from that bridge
> (while the devices still connect) My filter will get an IOCTL to remove
> child and in turn will change the child list and notify the PnP of child
> removal.
>
> If I understand correctly I need to get the child list of my underlying
> pci.sys driver and change it
>
> How Can I get the underlying child list of the pci.sys and change it (while
> notifying the PnP manager)
>
> Thanks
> Yossi
>
> —
> 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
>
>
>
>
> –
> Mark Roddy — 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
>
>
> —
> 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
>
>
> —
> 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
>
> —
> 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
>


Mark Roddy

Our solution to the faulty drivers is to initiate graceful removal (our system can detect when our device (pci bridge) is going to be removed)
And we manage to that using UM application that disable enable the device tree.
My idea was to do all that in KM

On the other hand, the OP could and in fact must, convince the pci bus driver to do a re-enumeration everytime the OP’s software detects >a device removal, as pci.sys only supports the hot plug interrupt mechanism (as in pccards) so it will be unaware of any other hot removal. >That is where IoInvalidateDeviceRelations comes in. Once again, this will not fix the faulty device drivers, it will simply convince pci.sys >to initiate PnP state transitions.

I tried to do , mean call IoInvalidateDeviceRelations and set number of child to zero when I expect unplug and immediately
The result was PnP crash, complaining inconsistency of the device tree.
I suspect the problem is that my tree has grandchildren which suddenly removed when I report their father (my bridge son) removal.

Cant I use the eject property and report my devices as being ejected ?

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Tuesday, June 17, 2008 1:59 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] bus enumartion from filter driver

The OP is facing a problem that we have considerable experience with at Stratus Technologies. His estimation that many pci device drivers will not behave well under suprise removal is correct, many will hang or crash the system. His solution is difficult to implement, as you point out, and is going in the wrong direction. Most of the pci drivers we have put through our surprise removal torture chamber (our systems have hot removable customer replaceable PCI busses that we stress test the heck out of) fail, and fail because they are not coded with any awareness that the hardware they communicate with can disappear. The hardware disappears regardless of what the OP (or Stratus) does with PnP state for the device. Surprise Removal state is a result of detecting vanished hardware, putting off the transition to Surprise Removal state does not somehow defer the removal of the hardware, and consequently the faulty pci device drivers will fail just as much after the OP manages to defer the transition as they did before he made these useless changes.

On the other hand, the OP could and in fact must, convince the pci bus driver to do a re-enumeration everytime the OP’s software detects a device removal, as pci.sys only supports the hot plug interrupt mechanism (as in pccards) so it will be unaware of any other hot removal. That is where IoInvalidateDeviceRelations comes in. Once again, this will not fix the faulty device drivers, it will simply convince pci.sys to initiate PnP state transitions.

What is the poor OP to do? Unfortunately the only answer is to work with the vendors to convince them to fix their drivers. Stratus gave a presentation on ‘Driver Hardening’ at WinHec a few years ago that outlined the steps required to write a driver that can handle losing its hardware. It actually isn’t rocket science. Of course, unless the OP has some leverage with every manufacturer out there who has devices that can be plugged into the OP’s system, this is not a good answer.

On Tue, Jun 17, 2008 at 5:02 AM, Doron Holan > wrote:

You cannot initiate a graceful remove in kernel, that is not exposed to WDM so KMDF cannot do anything magical. That means you must have the UM app do it based off of a notification from your driver

>And update pci.sys , so pci.sys will delete the PDOs.

Do not think there is a way to do this unless you somehow make pci think it is a pccard slot

> And in the general case can filter driver above bus driver can have any control on the device list that the bus report to the PnP ?

Not really, no. if you do intercept QDR(BusRelations) you have to fully simulate the pnp manager’s behavior and there are many aspects of that behavior that you cannot fake out b/c you do not have the interfaces to the rest of the system that a pnp state change uses, esp resource arbitration interfaces and the channel to the user mode pnp manager.

> How can I intercept PnP IRPs that directed to my lower driver (pci.sys) using KMDF.

I do not understand the question. You have a wdm preprocess routine in kmdf which lets you see all incoming pnp irps. If you mean all pnp irps that KMDF sends down the stack, no there is no hook for that, but there is no real need to hook any of these as far as I can see (you can always post process in a completion routine you set in your preprocess routine)

d

From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.commailto:xxxxx] On Behalf Of Yossi Leybovich
Sent: Tuesday, June 17, 2008 1:49 AM

To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

HI Doron

My bridge want to fully support hot plug/unplug of devices sits on the bus under it.

We found that many PCI devices does not support hot plug/unplug specially display devices .

But we do see that most of the devices do support gracefully removal .

I want to get interrupt from my bridge when it sense that there is going to be surprise removal (we have an algorithm to determine that in our system ) and notify the PnP so it will initiate graceful removal.

My solution right now is to have application in user space that will wait for my driver event to disable/enable the devices under my bridge.

When my filter get interrupt from the bridge it set the event and the application disable/enable the devices.

And this works fine (as u can remove/disable device even if it physically still there)

Is there is any way to that in KMDF? Without using use space application.

How can I initiate graceful removal from within kernel , so the PnP will sends query removal and removal to the devices? And update pci.sys , so pci.sys will delete the PDOs.

And in the general case can filter driver above bus driver can have any control on the device list that the bus report to the PnP ?

I can see various cases where vendors will want to report/not report devices they created to the PnP.

One more question :

How can I intercept PnP IRPs that directed to my lower driver (pci.sys) using KMDF.

Thanks

Yossi

From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.commailto:xxxxx] On Behalf Of Doron Holan
Sent: Monday, June 16, 2008 9:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

Yossi, you cannot make PDOs that you do not own disappear. If PCI thinks that they have been reported as present and then you report them as missing, there is a state change that PCI will miss that is very important. PNP will send a surprise remove + remove and expect PCI to delete the PDO on the remove (b/c it was reported missing). PCI will not know this and will keep the PDO around, violating the pnp state rules and will blow up soon there after.

Let me reemphasize this: you are going down a path that is pure hackery that will not get you want you want, even for test purposes this is a very very bad idea.

d

From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.commailto:xxxxx] On Behalf Of Mark Roddy
Sent: Monday, June 16, 2008 3:19 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] bus enumartion from filter driver

The list is obtained by filtering IRP_MN_QUERY_DEVICE_RELATIONS and examining the output from the BusRelations subtype of this request.If you want to provoke PnP do do a re-enumeration use IoInvalidateDeviceRelations.

On Mon, Jun 16, 2008 at 5:48 AM, Yossi Leybovich > wrote:

Hi all

I am writing filter driver for pci bridge the filter will be upper filter for the PCI.sys driver.
My driver is KMDF driver.
I want to intercept all PnP IRPs that go down to the pci.sys driver.
How can I do that using WDF driver?

My goal is to simulate add/remove (eject) of devices from that bridge (while the devices still connect) My filter will get an IOCTL to remove child and in turn will change the child list and notify the PnP of child removal.

If I understand correctly I need to get the child list of my underlying pci.sys driver and change it

How Can I get the underlying child list of the pci.sys and change it (while notifying the PnP manager)

Thanks
Yossi


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


Mark Roddy — 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


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


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


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


Mark Roddy — 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</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

Unless your system can prevent the actual physical removal of your
bridge until your graceful removal operation is complete, there is no
point in going down that path.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Yossi Leybovich
Sent: Tuesday, June 17, 2008 8:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

Our solution to the faulty drivers is to initiate graceful removal (our
system can detect when our device (pci bridge) is going to be removed)

And we manage to that using UM application that disable enable the
device tree.

My idea was to do all that in KM

On the other hand, the OP could and in fact must, convince the pci bus
driver to do a re-enumeration everytime the OP’s software detects >a
device removal, as pci.sys only supports the hot plug interrupt
mechanism (as in pccards) so it will be unaware of any other hot
removal. >That is where IoInvalidateDeviceRelations comes in. Once
again, this will not fix the faulty device drivers, it will simply
convince pci.sys >to initiate PnP state transitions.

I tried to do , mean call IoInvalidateDeviceRelations and set number
of child to zero when I expect unplug and immediately

The result was PnP crash, complaining inconsistency of the device tree.

I suspect the problem is that my tree has grandchildren which suddenly
removed when I report their father (my bridge son) removal.

Cant I use the eject property and report my devices as being ejected ?

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Tuesday, June 17, 2008 1:59 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] bus enumartion from filter driver

The OP is facing a problem that we have considerable experience with at
Stratus Technologies. His estimation that many pci device drivers will
not behave well under suprise removal is correct, many will hang or
crash the system. His solution is difficult to implement, as you point
out, and is going in the wrong direction. Most of the pci drivers we
have put through our surprise removal torture chamber (our systems have
hot removable customer replaceable PCI busses that we stress test the
heck out of) fail, and fail because they are not coded with any
awareness that the hardware they communicate with can disappear. The
hardware disappears regardless of what the OP (or Stratus) does with PnP
state for the device. Surprise Removal state is a result of detecting
vanished hardware, putting off the transition to Surprise Removal state
does not somehow defer the removal of the hardware, and consequently the
faulty pci device drivers will fail just as much after the OP manages to
defer the transition as they did before he made these useless changes.

On the other hand, the OP could and in fact must, convince the pci bus
driver to do a re-enumeration everytime the OP’s software detects a
device removal, as pci.sys only supports the hot plug interrupt
mechanism (as in pccards) so it will be unaware of any other hot
removal. That is where IoInvalidateDeviceRelations comes in. Once again,
this will not fix the faulty device drivers, it will simply convince
pci.sys to initiate PnP state transitions.

What is the poor OP to do? Unfortunately the only answer is to work with
the vendors to convince them to fix their drivers. Stratus gave a
presentation on ‘Driver Hardening’ at WinHec a few years ago that
outlined the steps required to write a driver that can handle losing its
hardware. It actually isn’t rocket science. Of course, unless the OP has
some leverage with every manufacturer out there who has devices that can
be plugged into the OP’s system, this is not a good answer.

On Tue, Jun 17, 2008 at 5:02 AM, Doron Holan
wrote:

You cannot initiate a graceful remove in kernel, that is not exposed to
WDM so KMDF cannot do anything magical. That means you must have the UM
app do it based off of a notification from your driver

>And update pci.sys , so pci.sys will delete the PDOs.

Do not think there is a way to do this unless you somehow make pci think
it is a pccard slot

> And in the general case can filter driver above bus driver can have
any control on the device list that the bus report to the PnP ?

Not really, no. if you do intercept QDR(BusRelations) you have to fully
simulate the pnp manager’s behavior and there are many aspects of that
behavior that you cannot fake out b/c you do not have the interfaces to
the rest of the system that a pnp state change uses, esp resource
arbitration interfaces and the channel to the user mode pnp manager.

> How can I intercept PnP IRPs that directed to my lower driver
(pci.sys) using KMDF.

I do not understand the question. You have a wdm preprocess routine in
kmdf which lets you see all incoming pnp irps. If you mean all pnp irps
that KMDF sends down the stack, no there is no hook for that, but there
is no real need to hook any of these as far as I can see (you can always
post process in a completion routine you set in your preprocess routine)

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Yossi Leybovich
Sent: Tuesday, June 17, 2008 1:49 AM

To: Windows System Software Devs Interest List

Subject: RE: [ntdev] bus enumartion from filter driver

HI Doron

My bridge want to fully support hot plug/unplug of devices sits on the
bus under it.

We found that many PCI devices does not support hot plug/unplug
specially display devices .

But we do see that most of the devices do support gracefully removal .

I want to get interrupt from my bridge when it sense that there is going
to be surprise removal (we have an algorithm to determine that in our
system ) and notify the PnP so it will initiate graceful removal.

My solution right now is to have application in user space that will
wait for my driver event to disable/enable the devices under my bridge.

When my filter get interrupt from the bridge it set the event and the
application disable/enable the devices.

And this works fine (as u can remove/disable device even if it
physically still there)

Is there is any way to that in KMDF? Without using use space
application.

How can I initiate graceful removal from within kernel , so the PnP will
sends query removal and removal to the devices? And update pci.sys , so
pci.sys will delete the PDOs.

And in the general case can filter driver above bus driver can have any
control on the device list that the bus report to the PnP ?

I can see various cases where vendors will want to report/not report
devices they created to the PnP.

One more question :

How can I intercept PnP IRPs that directed to my lower driver (pci.sys)
using KMDF.

Thanks

Yossi

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 16, 2008 9:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

Yossi, you cannot make PDOs that you do not own disappear. If PCI
thinks that they have been reported as present and then you report them
as missing, there is a state change that PCI will miss that is very
important. PNP will send a surprise remove + remove and expect PCI to
delete the PDO on the remove (b/c it was reported missing). PCI will
not know this and will keep the PDO around, violating the pnp state
rules and will blow up soon there after.

Let me reemphasize this: you are going down a path that is pure hackery
that will not get you want you want, even for test purposes this is a
very very bad idea.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, June 16, 2008 3:19 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] bus enumartion from filter driver

The list is obtained by filtering IRP_MN_QUERY_DEVICE_RELATIONS and
examining the output from the BusRelations subtype of this request.If
you want to provoke PnP do do a re-enumeration use
IoInvalidateDeviceRelations.

On Mon, Jun 16, 2008 at 5:48 AM, Yossi Leybovich
wrote:

Hi all

I am writing filter driver for pci bridge the filter will be upper
filter for the PCI.sys driver.
My driver is KMDF driver.
I want to intercept all PnP IRPs that go down to the pci.sys driver.
How can I do that using WDF driver?

My goal is to simulate add/remove (eject) of devices from that bridge
(while the devices still connect) My filter will get an IOCTL to remove
child and in turn will change the child list and notify the PnP of child
removal.

If I understand correctly I need to get the child list of my underlying
pci.sys driver and change it

How Can I get the underlying child list of the pci.sys and change it
(while notifying the PnP manager)

Thanks
Yossi


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


Mark Roddy — 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


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


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



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


Mark Roddy — 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


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

Yes my system can indentify physical removal of device few msec before it actually removed .
So we have few msec to do the graceful removal

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Tuesday, June 17, 2008 3:15 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

Unless your system can prevent the actual physical removal of your bridge until your graceful removal operation is complete, there is no point in going down that path.


From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Yossi Leybovich
Sent: Tuesday, June 17, 2008 8:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

Our solution to the faulty drivers is to initiate graceful removal (our system can detect when our device (pci bridge) is going to be removed)
And we manage to that using UM application that disable enable the device tree.
My idea was to do all that in KM

On the other hand, the OP could and in fact must, convince the pci bus driver to do a re-enumeration everytime the OP’s software detects >a device removal, as pci.sys only supports the hot plug interrupt mechanism (as in pccards) so it will be unaware of any other hot removal. >That is where IoInvalidateDeviceRelations comes in. Once again, this will not fix the faulty device drivers, it will simply convince pci.sys >to initiate PnP state transitions.

I tried to do , mean call IoInvalidateDeviceRelations and set number of child to zero when I expect unplug and immediately
The result was PnP crash, complaining inconsistency of the device tree.
I suspect the problem is that my tree has grandchildren which suddenly removed when I report their father (my bridge son) removal.

Cant I use the eject property and report my devices as being ejected ?

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Tuesday, June 17, 2008 1:59 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] bus enumartion from filter driver

The OP is facing a problem that we have considerable experience with at Stratus Technologies. His estimation that many pci device drivers will not behave well under suprise removal is correct, many will hang or crash the system. His solution is difficult to implement, as you point out, and is going in the wrong direction. Most of the pci drivers we have put through our surprise removal torture chamber (our systems have hot removable customer replaceable PCI busses that we stress test the heck out of) fail, and fail because they are not coded with any awareness that the hardware they communicate with can disappear. The hardware disappears regardless of what the OP (or Stratus) does with PnP state for the device. Surprise Removal state is a result of detecting vanished hardware, putting off the transition to Surprise Removal state does not somehow defer the removal of the hardware, and consequently the faulty pci device drivers will fail just as much after the OP manages to defer the transition as they did before he made these useless changes.

On the other hand, the OP could and in fact must, convince the pci bus driver to do a re-enumeration everytime the OP’s software detects a device removal, as pci.sys only supports the hot plug interrupt mechanism (as in pccards) so it will be unaware of any other hot removal. That is where IoInvalidateDeviceRelations comes in. Once again, this will not fix the faulty device drivers, it will simply convince pci.sys to initiate PnP state transitions.

What is the poor OP to do? Unfortunately the only answer is to work with the vendors to convince them to fix their drivers. Stratus gave a presentation on ‘Driver Hardening’ at WinHec a few years ago that outlined the steps required to write a driver that can handle losing its hardware. It actually isn’t rocket science. Of course, unless the OP has some leverage with every manufacturer out there who has devices that can be plugged into the OP’s system, this is not a good answer.

On Tue, Jun 17, 2008 at 5:02 AM, Doron Holan > wrote:

You cannot initiate a graceful remove in kernel, that is not exposed to WDM so KMDF cannot do anything magical. That means you must have the UM app do it based off of a notification from your driver

>And update pci.sys , so pci.sys will delete the PDOs.

Do not think there is a way to do this unless you somehow make pci think it is a pccard slot

> And in the general case can filter driver above bus driver can have any control on the device list that the bus report to the PnP ?

Not really, no. if you do intercept QDR(BusRelations) you have to fully simulate the pnp manager’s behavior and there are many aspects of that behavior that you cannot fake out b/c you do not have the interfaces to the rest of the system that a pnp state change uses, esp resource arbitration interfaces and the channel to the user mode pnp manager.

> How can I intercept PnP IRPs that directed to my lower driver (pci.sys) using KMDF.

I do not understand the question. You have a wdm preprocess routine in kmdf which lets you see all incoming pnp irps. If you mean all pnp irps that KMDF sends down the stack, no there is no hook for that, but there is no real need to hook any of these as far as I can see (you can always post process in a completion routine you set in your preprocess routine)

d

From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.commailto:xxxxx] On Behalf Of Yossi Leybovich
Sent: Tuesday, June 17, 2008 1:49 AM

To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

HI Doron

My bridge want to fully support hot plug/unplug of devices sits on the bus under it.

We found that many PCI devices does not support hot plug/unplug specially display devices .

But we do see that most of the devices do support gracefully removal .

I want to get interrupt from my bridge when it sense that there is going to be surprise removal (we have an algorithm to determine that in our system ) and notify the PnP so it will initiate graceful removal.

My solution right now is to have application in user space that will wait for my driver event to disable/enable the devices under my bridge.

When my filter get interrupt from the bridge it set the event and the application disable/enable the devices.

And this works fine (as u can remove/disable device even if it physically still there)

Is there is any way to that in KMDF? Without using use space application.

How can I initiate graceful removal from within kernel , so the PnP will sends query removal and removal to the devices? And update pci.sys , so pci.sys will delete the PDOs.

And in the general case can filter driver above bus driver can have any control on the device list that the bus report to the PnP ?

I can see various cases where vendors will want to report/not report devices they created to the PnP.

One more question :

How can I intercept PnP IRPs that directed to my lower driver (pci.sys) using KMDF.

Thanks

Yossi

From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.commailto:xxxxx] On Behalf Of Doron Holan
Sent: Monday, June 16, 2008 9:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

Yossi, you cannot make PDOs that you do not own disappear. If PCI thinks that they have been reported as present and then you report them as missing, there is a state change that PCI will miss that is very important. PNP will send a surprise remove + remove and expect PCI to delete the PDO on the remove (b/c it was reported missing). PCI will not know this and will keep the PDO around, violating the pnp state rules and will blow up soon there after.

Let me reemphasize this: you are going down a path that is pure hackery that will not get you want you want, even for test purposes this is a very very bad idea.

d

From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.commailto:xxxxx] On Behalf Of Mark Roddy
Sent: Monday, June 16, 2008 3:19 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] bus enumartion from filter driver

The list is obtained by filtering IRP_MN_QUERY_DEVICE_RELATIONS and examining the output from the BusRelations subtype of this request.If you want to provoke PnP do do a re-enumeration use IoInvalidateDeviceRelations.

On Mon, Jun 16, 2008 at 5:48 AM, Yossi Leybovich > wrote:

Hi all

I am writing filter driver for pci bridge the filter will be upper filter for the PCI.sys driver.
My driver is KMDF driver.
I want to intercept all PnP IRPs that go down to the pci.sys driver.
How can I do that using WDF driver?

My goal is to simulate add/remove (eject) of devices from that bridge (while the devices still connect) My filter will get an IOCTL to remove child and in turn will change the child list and notify the PnP of child removal.

If I understand correctly I need to get the child list of my underlying pci.sys driver and change it

How Can I get the underlying child list of the pci.sys and change it (while notifying the PnP manager)

Thanks
Yossi


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


Mark Roddy — 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


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


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


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


Mark Roddy — 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


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


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</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

That is not going to work. As Doron pointed out, you need to get up to
user mode and back down the device stack. Even if you could somehow get
polite removal to occur within your few ms timeframe, what happens if
one of your devices says ‘no thanks, I don’t want to be removed now’?
Times up - it is gone anyway and you are back to the actual problem.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Yossi Leybovich
Sent: Tuesday, June 17, 2008 10:38 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

Yes my system can indentify physical removal of device few msec before
it actually removed .

So we have few msec to do the graceful removal

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Tuesday, June 17, 2008 3:15 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

Unless your system can prevent the actual physical removal of your
bridge until your graceful removal operation is complete, there is no
point in going down that path.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Yossi Leybovich
Sent: Tuesday, June 17, 2008 8:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

Our solution to the faulty drivers is to initiate graceful removal (our
system can detect when our device (pci bridge) is going to be removed)

And we manage to that using UM application that disable enable the
device tree.

My idea was to do all that in KM

On the other hand, the OP could and in fact must, convince the pci bus
driver to do a re-enumeration everytime the OP’s software detects >a
device removal, as pci.sys only supports the hot plug interrupt
mechanism (as in pccards) so it will be unaware of any other hot
removal. >That is where IoInvalidateDeviceRelations comes in. Once
again, this will not fix the faulty device drivers, it will simply
convince pci.sys >to initiate PnP state transitions.

I tried to do , mean call IoInvalidateDeviceRelations and set number
of child to zero when I expect unplug and immediately

The result was PnP crash, complaining inconsistency of the device tree.

I suspect the problem is that my tree has grandchildren which suddenly
removed when I report their father (my bridge son) removal.

Cant I use the eject property and report my devices as being ejected ?

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Tuesday, June 17, 2008 1:59 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] bus enumartion from filter driver

The OP is facing a problem that we have considerable experience with at
Stratus Technologies. His estimation that many pci device drivers will
not behave well under suprise removal is correct, many will hang or
crash the system. His solution is difficult to implement, as you point
out, and is going in the wrong direction. Most of the pci drivers we
have put through our surprise removal torture chamber (our systems have
hot removable customer replaceable PCI busses that we stress test the
heck out of) fail, and fail because they are not coded with any
awareness that the hardware they communicate with can disappear. The
hardware disappears regardless of what the OP (or Stratus) does with PnP
state for the device. Surprise Removal state is a result of detecting
vanished hardware, putting off the transition to Surprise Removal state
does not somehow defer the removal of the hardware, and consequently the
faulty pci device drivers will fail just as much after the OP manages to
defer the transition as they did before he made these useless changes.

On the other hand, the OP could and in fact must, convince the pci bus
driver to do a re-enumeration everytime the OP’s software detects a
device removal, as pci.sys only supports the hot plug interrupt
mechanism (as in pccards) so it will be unaware of any other hot
removal. That is where IoInvalidateDeviceRelations comes in. Once again,
this will not fix the faulty device drivers, it will simply convince
pci.sys to initiate PnP state transitions.

What is the poor OP to do? Unfortunately the only answer is to work with
the vendors to convince them to fix their drivers. Stratus gave a
presentation on ‘Driver Hardening’ at WinHec a few years ago that
outlined the steps required to write a driver that can handle losing its
hardware. It actually isn’t rocket science. Of course, unless the OP has
some leverage with every manufacturer out there who has devices that can
be plugged into the OP’s system, this is not a good answer.

On Tue, Jun 17, 2008 at 5:02 AM, Doron Holan
wrote:

You cannot initiate a graceful remove in kernel, that is not exposed to
WDM so KMDF cannot do anything magical. That means you must have the UM
app do it based off of a notification from your driver

>And update pci.sys , so pci.sys will delete the PDOs.

Do not think there is a way to do this unless you somehow make pci think
it is a pccard slot

> And in the general case can filter driver above bus driver can have
any control on the device list that the bus report to the PnP ?

Not really, no. if you do intercept QDR(BusRelations) you have to fully
simulate the pnp manager’s behavior and there are many aspects of that
behavior that you cannot fake out b/c you do not have the interfaces to
the rest of the system that a pnp state change uses, esp resource
arbitration interfaces and the channel to the user mode pnp manager.

> How can I intercept PnP IRPs that directed to my lower driver
(pci.sys) using KMDF.

I do not understand the question. You have a wdm preprocess routine in
kmdf which lets you see all incoming pnp irps. If you mean all pnp irps
that KMDF sends down the stack, no there is no hook for that, but there
is no real need to hook any of these as far as I can see (you can always
post process in a completion routine you set in your preprocess routine)

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Yossi Leybovich
Sent: Tuesday, June 17, 2008 1:49 AM

To: Windows System Software Devs Interest List

Subject: RE: [ntdev] bus enumartion from filter driver

HI Doron

My bridge want to fully support hot plug/unplug of devices sits on the
bus under it.

We found that many PCI devices does not support hot plug/unplug
specially display devices .

But we do see that most of the devices do support gracefully removal .

I want to get interrupt from my bridge when it sense that there is going
to be surprise removal (we have an algorithm to determine that in our
system ) and notify the PnP so it will initiate graceful removal.

My solution right now is to have application in user space that will
wait for my driver event to disable/enable the devices under my bridge.

When my filter get interrupt from the bridge it set the event and the
application disable/enable the devices.

And this works fine (as u can remove/disable device even if it
physically still there)

Is there is any way to that in KMDF? Without using use space
application.

How can I initiate graceful removal from within kernel , so the PnP will
sends query removal and removal to the devices? And update pci.sys , so
pci.sys will delete the PDOs.

And in the general case can filter driver above bus driver can have any
control on the device list that the bus report to the PnP ?

I can see various cases where vendors will want to report/not report
devices they created to the PnP.

One more question :

How can I intercept PnP IRPs that directed to my lower driver (pci.sys)
using KMDF.

Thanks

Yossi

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 16, 2008 9:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] bus enumartion from filter driver

Yossi, you cannot make PDOs that you do not own disappear. If PCI
thinks that they have been reported as present and then you report them
as missing, there is a state change that PCI will miss that is very
important. PNP will send a surprise remove + remove and expect PCI to
delete the PDO on the remove (b/c it was reported missing). PCI will
not know this and will keep the PDO around, violating the pnp state
rules and will blow up soon there after.

Let me reemphasize this: you are going down a path that is pure hackery
that will not get you want you want, even for test purposes this is a
very very bad idea.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, June 16, 2008 3:19 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] bus enumartion from filter driver

The list is obtained by filtering IRP_MN_QUERY_DEVICE_RELATIONS and
examining the output from the BusRelations subtype of this request.If
you want to provoke PnP do do a re-enumeration use
IoInvalidateDeviceRelations.

On Mon, Jun 16, 2008 at 5:48 AM, Yossi Leybovich
wrote:

Hi all

I am writing filter driver for pci bridge the filter will be upper
filter for the PCI.sys driver.
My driver is KMDF driver.
I want to intercept all PnP IRPs that go down to the pci.sys driver.
How can I do that using WDF driver?

My goal is to simulate add/remove (eject) of devices from that bridge
(while the devices still connect) My filter will get an IOCTL to remove
child and in turn will change the child list and notify the PnP of child
removal.

If I understand correctly I need to get the child list of my underlying
pci.sys driver and change it

How Can I get the underlying child list of the pci.sys and change it
(while notifying the PnP manager)

Thanks
Yossi


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


Mark Roddy — 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


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


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



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


Mark Roddy — 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


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


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


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