Roman Kononov wrote:
Peter Stuge wrote:
But PCI config accesses are not atomic operations. Is there a guarantee that the other CPUs are not in the middle of doing a PCI access already?
And even if they are actually doing something else, perhaps they (erroneously? but we don't want to break them anyway) rely on 0xcfc being what they set it to in the last PCI config access?
By making all the CPUs spinning inside your DPC you avoid these problems. The Windoze kernel protects itself and does not execute scheduled DPC when the CPU is in the middle of a PCI access or anything similar. For sure, when a CPU makes a PCI access its "IRQL" is raised to "HIGH_LEVEL", which means that a dedicated spin lock is acquired and that CPU's interrupts are disabled.
I did not take the above statement about IRQL from an official document, I made it based on my experience and common sense.
Regards,
Roman
Apparently, this is the only solution right now because the Hal***BusDataByOffset() function is _not_ working as expected.
My latest test results with 2 different PCs with WIndows XP SP2 shows that HalGetBusDataByOffset() is not a stable function, it works in one of the test platform and crashes in others. While the HalSetBusDataByOffset() is _not_ working at all. I think the symbol is defined in the kernel but may not be implemented in Win XP SP2.
Moreover, direct port I/O was working flawlessly with the older flashrom that I port to windows back then. I think the "DPC" trick will guarantee the atomic operation and will give us the level of confidence to do the direct port I/O.
I'll be reporting as soon as the DPC version of the direct port I/O driver routine has been tested.
Regards, Darmawan Salihun