Hello,
I am trying to synchronize the access to my mapped PCI registers (WRITE_REGISTER_ULONG) in a WDM driver. Because there are a lot of shared resources I’m using KeSynchronizeExecution at a PCI access to ANY of the registers so I don’t accidently access the same register at the same time on a multicore system.
See related post:
http://www.osronline.com/showThread.cfm?link=115719
What is your experience about this approach? Does it lead to a significant performance decrease or other problems?
Usually my DeviceIoControl-calls are serialized (not overlapped, synchronized with critical sections), but PnP/Power-IRPs and the ISR may appear ar the same time. So there should not be much contention on the ISR spin lock.
Seems like overkill to me overall. Clearly for memory that is accessed by the ISR and other code, you need synchronization. KeAcquire/ReleaseInterruptSpinLock is probably a better solution than KeSynchronizeExecution at this point, and it is certainly much easier to read the code flow. For memory that is only accessed by non ISR code, a normal spinlock is fine.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmx.de
Sent: Wednesday, December 5, 2012 9:22 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KeSynchronizeExecution at every PCI access
Hello,
I am trying to synchronize the access to my mapped PCI registers (WRITE_REGISTER_ULONG) in a WDM driver. Because there are a lot of shared resources I’m using KeSynchronizeExecution at a PCI access to ANY of the registers so I don’t accidently access the same register at the same time on a multicore system.
See related post:
http://www.osronline.com/showThread.cfm?link=115719
What is your experience about this approach? Does it lead to a significant performance decrease or other problems?
Usually my DeviceIoControl-calls are serialized (not overlapped, synchronized with critical sections), but PnP/Power-IRPs and the ISR may appear ar the same time. So there should not be much contention on the ISR spin lock.
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
KeSynchronizeExecution is required only if you are accessing the PCI
registers from an ISR and some other level, such as PASSIVE_LEVEL or
DISPATCH_LEVEL. It has nothing to do with multicore systems, and is never
done in tbe ISR, which is implicitly serialized across multiple cores
using te interrupt spin lock.
Since you have said nothing about the contexts in which you access the
registers, or what the access patterns might be, there is no way to answer
this question.
For example, if you cannot get an interrupt until you request a transfer,
you don’t ned to synchronize with the ISR if you are not touching the
registers in a pattern that cannot involve concurrency with the ISR.
Hello,
I am trying to synchronize the access to my mapped PCI registers
(WRITE_REGISTER_ULONG) in a WDM driver. Because there are a lot of shared
resources I’m using KeSynchronizeExecution at a PCI access to ANY of the
registers so I don’t accidently access the same register at the same time
on a multicore system.
See related post:
http://www.osronline.com/showThread.cfm?link=115719
What is your experience about this approach? Does it lead to a significant
performance decrease or other problems?
Usually my DeviceIoControl-calls are serialized (not overlapped,
synchronized with critical sections), but PnP/Power-IRPs and the ISR may
appear ar the same time. So there should not be much contention on the ISR
spin lock.
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
It reminds me a sad story that a HW guy I knew of. He had a bug in his
block of design where the chip would hang while some MMIO registers are
being accessed simultaneously from cores. It wasn’t caught in pre-silicon
verifications and simulations.The workaround in the sw is so ugly such that
we had to tape-out another chip to fix the problem costing half million at
the time. His life in the org was miserable and eventually left.
Calvin
Sent from my PC.
On Wed, Dec 5, 2012 at 9:21 AM, wrote:
>
> Hello,
> I am trying to synchronize the access to my mapped PCI registers
> (WRITE_REGISTER_ULONG) in a WDM driver. Because there are a lot of shared
> resources I’m using KeSynchronizeExecution at a PCI access to ANY of the
> registers so I don’t accidently access the same register at the same time
> on a multicore system.
>
> See related post:
> http://www.osronline.com/showThread.cfm?link=115719
>
> What is your experience about this approach? Does it lead to a significant
> performance decrease or other problems?
>
> Usually my DeviceIoControl-calls are serialized (not overlapped,
> synchronized with critical sections), but PnP/Power-IRPs and the ISR may
> appear ar the same time. So there should not be much contention on the ISR
> spin lock.
>
> —
> 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
>
xxxxx@gmx.de wrote:
I am trying to synchronize the access to my mapped PCI registers (WRITE_REGISTER_ULONG) in a WDM driver. Because there are a lot of shared resources I’m using KeSynchronizeExecution at a PCI access to ANY of the registers so I don’t accidently access the same register at the same time on a multicore system.
Remember that you generally only need to protect registers that can be
both read and written (just like normal data). If you have read-only
status registers, you can read those from multiple cores without
protection. If you have a set of registers that constitute a coherent
“state”, you might need to protect those so they get written atomically.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>He had a bug in his block of design where the chip would hang while some MMIO registers are
being accessed simultaneously from cores.
I had to deal with a PCI chip that would hang on PCI burst transactions. Some ugly workarounds needed to be made to make sure no two sequential requesters were accessed one after another. Basically, we had to break any possible burst.
“Good” chip bugs are fun to work with and it’s how one gets paid but
sometimes they can be dreadful to SW folks. I was more than once in
situation that a person several levels above in the command chain came to
my office asked, “we are going to tape out the chip but we have this and
that bug that we won’t be able to fix without severely delay the
schedule. We will miss the product cycle hence we may have to cancel the
project. Do you think we can workaround it in the driver?”. Often those are
bugs with known and unknown implications which isn’t very clear if a viable
solution exists at the time.
Now, if I say yes, that I’m signed up for the bug, it becomes MY BUG. When
the chip came back, I will have to work my ass off often found myself
didn’t even have breakfast at dinner time. If I say no, they may delay or
cancel the chip which causes more problems. If I say I don’t know or plain
BS too many times, they would think I’m incompetent for my work.
If I said yes but ended up failing to workaround the problem such that the
chip won’t sell without heavy discount, they would say, well ABC told us he
can fix it…
If I said no and the project was cancelled, they would say ABC said we
can’t do it. People tend to remember the bad results but not the context
and details.
What would you guys do?
Calvin
Sent from my PC on WIN8
On Wed, Dec 5, 2012 at 1:07 PM, wrote:
> >He had a bug in his block of design where the chip would hang while some
> MMIO registers are
> being accessed simultaneously from cores.
>
> I had to deal with a PCI chip that would hang on PCI burst transactions.
> Some ugly workarounds needed to be made to make sure no two sequential
> requesters were accessed one after another. Basically, we had to break any
> possible burst.
>
> —
> 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
>
>Now, if I say yes, that I’m signed up for the bug, it becomes MY BUG. When the chip came back, I will
have to work my ass off often found myself didn’t even have breakfast at dinner time. If I say no, they
may delay or cancel the chip which causes more problems. If I say I don’t know or plain BS too many
times, they would think I’m incompetent for my work.
I usually try to give odds in cases like this, which to me to me is accurate communication. This also allows management to evaluate risk in context more clearly. It’s like if I said there was a 99.9% chance your plane would not crash, even though it’s only a small chance of a problem, the severity of the consequences makes 99.9% chance of success high risk. I tend not to give an absolute yes or no, even though binary answers are emotionally satisfying to many people, the reality may turn out yes I can work around it in the driver but performance is impacted. It depends on your definition of “work around”. A decision based on the odds and consequences, is something completely different. There is context and norms for decisions, like every time they launched the space shuttle, there was about a 1 in 50 chance they were about to kill 7 people, which was viewed as acceptable in the context at NASA.
Jan