Windows does not require/load any driver for the Host PCI
Bridge (0.0.0). This can be checked by using the Device Manager or devcon tool in
DDK. Machine.inf also shows that the device (Host PCI Bridge) does not need any driver.
I have to read some vendor specific information from PCI host bridge. For this I have a non-PNP driver that looks at PCI Configuration port CF8/CFC to read the information. Ideally I would like to use a upper filter driver for the PCI bus driver and use busInterfaceStandard.GetBusData.
Given that PCI host bridge does not have a driver, what other option do I have? I do not want to muck with the host controller too much, just read few vendor specific bytes at boot up time.
You keep saying that Windows does not “require/load any driver for the Host
PCI”. How therefore can it be used by drivers? How can accesses to
0xCF8/0xCFC be coordinated? Having just traced in to ndis.sys from a driver
doing a read of the PCI Configuration registers for a device, I can assure
you that pci.sys ‘owns’ the PCI buss under Windows Server 2003 x86. It
calls into hal.dll to read & write those registers running at HIGH_LEVEL
with a spinlock. Therefore it might be that some would consider hal.dll to
‘own’ the PCI buss and I don’t know how Microsoft defines the owner, but
there is an owner and since the spinlock is internal to hal.dll that means
NO ONE ELSE can access those registers safely. I know for NDIS miniports on
the PCI buss that there is a provided method to read data from specific
devices and maybe a little reverse engineering or reading of the
documentation should help.
For the hackers and purists out there I think you could create a DPC for
each processor other than the one you are running on at the moment at
DISPATCH_LEVEL or higher. Those other DPCs must run a IRQL HIGH_LEVEL with
interrupts disabled. Then you may be able to access those registers on your
CPU after raising IRQL to HIGH_LEVEL. It still may be a little fragile and
any implementation will have to be tested rigorously.
wrote in message news:xxxxx@ntdev…
> Windows does not require/load any driver for the Host PCI
> Bridge (0.0.0). This can be checked by using the Device Manager or devcon
> tool in
> DDK. Machine.inf also shows that the device (Host PCI Bridge) does not
> need any driver.
>
> I have to read some vendor specific information from PCI host bridge. For
> this I have a non-PNP driver that looks at PCI Configuration port CF8/CFC
> to read the information. Ideally I would like to use a upper filter driver
> for the PCI bus driver and use busInterfaceStandard.GetBusData.
>
> Given that PCI host bridge does not have a driver, what other option do I
> have? I do not want to muck with the host controller too much, just read
> few vendor specific bytes at boot up time.
>
>
Of course, that would break if accesses to the registers by their rightful owner were done with a lock that doesn’t block DPCs, i.e. a non-spinlock. In such a case, one’s DPC could preempt a register read followed by a register write, violating atomicity.
-----Original Message-----
From: David Craig
Sent: Tuesday, March 17, 2009 22:09
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] PCI Host Bridge filter driver
You keep saying that Windows does not “require/load any driver for the Host
PCI”. How therefore can it be used by drivers? How can accesses to
0xCF8/0xCFC be coordinated? Having just traced in to ndis.sys from a driver
doing a read of the PCI Configuration registers for a device, I can assure
you that pci.sys ‘owns’ the PCI buss under Windows Server 2003 x86. It
calls into hal.dll to read & write those registers running at HIGH_LEVEL
with a spinlock. Therefore it might be that some would consider hal.dll to
‘own’ the PCI buss and I don’t know how Microsoft defines the owner, but
there is an owner and since the spinlock is internal to hal.dll that means
NO ONE ELSE can access those registers safely. I know for NDIS miniports on
the PCI buss that there is a provided method to read data from specific
devices and maybe a little reverse engineering or reading of the
documentation should help.
For the hackers and purists out there I think you could create a DPC for
each processor other than the one you are running on at the moment at
DISPATCH_LEVEL or higher. Those other DPCs must run a IRQL HIGH_LEVEL with
interrupts disabled. Then you may be able to access those registers on your
CPU after raising IRQL to HIGH_LEVEL. It still may be a little fragile and
any implementation will have to be tested rigorously.
wrote in message news:xxxxx@ntdev…
> Windows does not require/load any driver for the Host PCI
> Bridge (0.0.0). This can be checked by using the Device Manager or devcon
> tool in
> DDK. Machine.inf also shows that the device (Host PCI Bridge) does not
> need any driver.
>
> I have to read some vendor specific information from PCI host bridge. For
> this I have a non-PNP driver that looks at PCI Configuration port CF8/CFC
> to read the information. Ideally I would like to use a upper filter driver
> for the PCI bus driver and use busInterfaceStandard.GetBusData.
>
> Given that PCI host bridge does not have a driver, what other option do I
> have? I do not want to muck with the host controller too much, just read
> few vendor specific bytes at boot up time.
>
>
—
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
> Of course, that would break if accesses to the registers by their rightful owner were done
with a lock that doesn’t block DPCs, i.e. a non-spinlock.
IIRC, there is a doc that explicitly says that an access to PCI configuration space is protected by a spinlock
(although normally one would expect to do all configuration at low IRQL). Therefore, CPU corralling should work here. However, if a construct that allows preemption was used instead of a spinlock, then, indeed, “unautrorized” access might leave registers in inconsistent state…
Anton Bassov