Re: Interrupt handling in multi-processor environment
Re: Interrupt handling in multi-processor environment
- Subject: Re: Interrupt handling in multi-processor environment
- From: "mm w" <email@hidden>
- Date: Mon, 17 Nov 2008 09:17:50 -0800
hi Rob,
I answered you on this part (it sounds like you are porting existing
code, or try to apply foreign concepts to macos)
> (The context of this query is trying to serialise access to registers
> (including register reads) on a PCI device.
i will recommend to read this document carefully
http://developer.apple.com/documentation/DeviceDrivers/Conceptual/WritingDeviceDriver/IOService/chapter_4_section_6.html
Cheers!
On Sun, Nov 16, 2008 at 10:28 PM, Rob Cas <email@hidden> wrote:
> Hi,
>
> I'm trying to understand how IOSimpleLockLockDisableInterrupt works to
> prevent interrupt preemption in a multi-processor environment. Perhaps
> somebody could help clarify my (mis)understandings.
>
> IOSimpleLockLockDisableInterrupt() appears to disable interrupts (via
> ml_set_interrupts_enabled()) using the sti/cli instructions which act
> only on a single CPU.
>
> Does this mean that if such a lock is held by a task on the same
> workloop as an IOFilterInterruptEventSource, it is still possible for
> an interrupt filter function to be called via an interrupt occurring
> on a different CPU?
>
> Looking at how interrupts are delivered/controlled inside IOKit via
> IOInterruptControllers/IOSharedInterruptControllers,
> IOFilterInterruptEventSource, etc it looks like there is just a single
> 'master' interrupt controller (AppleACPICPUInterruptController)
> attached to just one of the CPUs that (ultimately) causes interrupts
> to be dispatched to the filter functions of
> IOFilterInterruptEventSources. Are interrupts from all CPUs somehow
> routed through to this single master interrupt controller?
>
> (The context of this query is trying to serialise access to registers
> (including register reads) on a PCI device.
>
> An alternative approach that occurs to me (if
> IOSimpleLockLockDisableInterrupt is not suitable) is to disable the
> IOFilterInterruptEventSource temporarily whilst the registers are
> accessed outside of the interrupt filter function, which has the
> side-effect of calling disableInterrupt() on the shared interrupt
> controller, thus preventing preemption by the interrupt filter
> function. I'm not sure whether disabling a shared interrupt controller
> for very brief times is a good idea though - will it have an adverse
> impact on other parts of the system sharing those interrupts.
> )
>
> Thanks in advance,
> Rob.
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-kernel mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
--
-mmw
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden