Date: Sat, 18 Dec 2010 14:24:34 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: freebsd-hackers@freebsd.org Subject: MONITOR/MWAIT question Message-ID: <201012182224.oBIMOYfl067212@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
Does anyone know if an IRET cancels/triggers a MONITOR event? Here's
the problem:
(1) main line kernel code is executing a MONITOR/MWAIT sequence.
It executes its MONITOR but has not yet gotten to the MWAIT.
(2) An interrupt occurs inbetween the MONITOR and the MWAIT.
This triggers/cancels the main-line MONITOR but that doesn't
help us (see below).
(3) The interrupt code itself executes a MONITOR but the data check
after the MONITOR determines the data has changed so MWAIT is
skipped (e.g. MONITOR, CMPL, JNE 2f ,MWAIT, 2:). Because the
data may have changed prior to the interrupt's MONITOR instruction
the MONITOR may not be triggered in this case.
Therefore the interrupt code leaves the monitor untriggered and
active. i.e. never ran MWAIT.
(4) The interrupt then IRETs.
(5) The main line code continues on and gets to its MWAIT instruction
which now waits for the trigger on the wrong MONITOR.
(6) We blow up (or at least, until the next interrupt/SMI/whatever
cancels the MWAIT).
If IRET does not trigger/cancel the monitor then any code using the
monitor/mwait sequence needs to somehow trigger/cancel it in the
CMPL/JNE path. Presumably this can be done by doing a fake monitor
on a stack address and then explicitly writing to it but it would
be nice if IRETQ also trigger/canceled it.
I can't find any documentation that clarifies whether IRET
triggers/cancels the MONITOR.
-Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012182224.oBIMOYfl067212>