MONITOR/MWAIT question

Matthew Dillon dillon at apollo.backplane.com
Sat Dec 18 22:39:17 UTC 2010


    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



More information about the freebsd-hackers mailing list