From owner-freebsd-current@FreeBSD.ORG Thu Jun 17 20:28:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAF7B16A4CE for ; Thu, 17 Jun 2004 20:28:46 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6877D43D5F for ; Thu, 17 Jun 2004 20:28:46 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i5HKRDx7009470; Thu, 17 Jun 2004 13:27:13 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i5HKRDMC009469; Thu, 17 Jun 2004 13:27:13 -0700 (PDT) (envelope-from dillon) Date: Thu, 17 Jun 2004 13:27:13 -0700 (PDT) From: Matthew Dillon Message-Id: <200406172027.i5HKRDMC009469@apollo.backplane.com> To: Don Bowman References: cc: Julian Elischer cc: "'current@freebsd.org'" Subject: RE: STI, HLT in acpi_cpu_idle_c1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2004 20:28:46 -0000 :> :> The whole point is for interrupts to be disabled when the :> HLT instruction :> *begins* execution (they're only disabled for one cycle). :> : :Ummm, doesn't STI *enable* interrupts? : :so you're saying the point is that on entry to :acpi_cpu_idle_c1, that the caller has done a CLI? :And that the STI then enables interrupts during the HLT :instruction? Ok, I'll try to explain it better. CLI - disable interrupts STI - enable interrupts HLT - halt the cpu until an interrupt occurs. If interrupts are disabled, this will halt the cpu until an NMI occurs. Now, there's a problem... the problem is that if you enable interrupts and halt (to wait for the next interrupt), then there is a one-instruction window where an interrupt might occur *BEFORE* you HLT. This interrupt may do something (such as schedule a thread) that means that you really don't want to halt now waiting for a *SECOND* interrupt to occur. In order to deal with this problem, Intel specified that the 'STI ; HLT' sequence of instructions will *GUARENTEE* that interrupts will remain disabled for one additional cycle, which gives HLT a chance to enter into its wait state. An interrupt occuring in between the STI and HLT would therefore cause the HLT to resume. In later cpu's Intel and Amd both guarentee the atomicy of the STI; HLT instruction combination. No interrupt will be allowed to take effect inbetween the instructions, no trap will occur. No NMI will occur... nothing (either that or, for an NMI, the cpu will fixup the interrupt flag and set the restart point to the STI rather then the HLT). For all intents and purposes you should treat 'STI; HLT' as a single instruction. If you stick a NOP in there you will screw everything up... it will make it possible for an interrupt to occur inbetween the STI and HLT, *BEFORE* the HLT enters its wait state. When the interrupt finishes HLT will enter its wait state and not resume again until a *SECOND* interrupt occurs, which is not what you want because you might be in a situation (such as during booting) where no other interrupt will occur or where most other interrupt sources might be disabled or non-functional (e.g. ACPI sleep). So, if the emulator is not coming out of the HLT it's a bug in the emulator. The STI; HLT sequence is correct. -Matt