On Sun, Jul 15, 2012 at 10:36 PM, Jakub Jermar <[email protected]> wrote: > On 07/14/2012 01:45 PM, Adam Hraska wrote: >> On Fri, Jul 13, 2012 at 12:23 AM, Jakub Jermar <[email protected]> wrote: >>> I noticed we now have conflicting implementations of >>> ipi_wait_for_idle(). Moreover you call yours before sending the IPI >>> while the mainline implementation calls it afterwards: >>> >>> +int l_apic_send_custom_ipi(uint8_t apicid, uint8_t vector) >>> +{ >>> + icr_t icr; >>> + >>> + /* Wait for a destination cpu to accept our previous ipi. */ >>> + ipi_wait_for_idle(); >>> >>> I guess doing it before can eliminate some waiting time by simply doing >>> some useful work before sending the next IPI, but on the other hand, you >>> proceed with uncertainty that the IPI has indeed been delivered when you >>> needed it. >> >> If I understood the documentation [1] correctly, the >> delivery status is "pending" until the destination cpu >> accepts the interrupt. That just means the destination >> cpu's APIC noted the IPI. Therefore, it does not indicate >> the IPI was dispatched to software and it definitely >> does not mean that software handled the IPI. >> >> As far as I can see, it is only used to avoid sending >> another IPI while sending the previous one is still >> in progress. The documentation does not specify what >> happens if we try to send another IPI and the previous >> has not yet been accepted but I am guessing bad things >> might happen, eg the previous IPI may be lost or the >> current one discarded. > > This makes sense.
I am sending a link to the Linux implementation for completeness like we have talked about in the meeting: http://lxr.linux.no/#linux+v3.4.4/arch/x86/include/asm/ipi.h#L61 Adam _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
