From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fzawr-0003u1-Kb for qemu-devel@nongnu.org; Sun, 09 Jul 2006 11:11:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fzawq-0003tp-TK for qemu-devel@nongnu.org; Sun, 09 Jul 2006 11:11:53 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fzawq-0003tm-Q3 for qemu-devel@nongnu.org; Sun, 09 Jul 2006 11:11:52 -0400 Received: from [81.29.64.88] (helo=mail.shareable.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1Fzaxj-0007XK-Lt for qemu-devel@nongnu.org; Sun, 09 Jul 2006 11:12:47 -0400 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.11.20060308/8.12.8) with ESMTP id k69FBoUb031455 for ; Sun, 9 Jul 2006 16:11:50 +0100 Received: (from jamie@localhost) by mail.shareable.org (8.12.11.20060308/8.12.8/Submit) id k69FBovs031453 for qemu-devel@nongnu.org; Sun, 9 Jul 2006 16:11:50 +0100 Date: Sun, 9 Jul 2006 16:11:49 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] add 'monitor' and 'mwait' instruction (update) Message-ID: <20060709151149.GA31080@mail.shareable.org> References: <44AD28AA.7050301@armiento.net> <44AFB038.9020101@armiento.net> <44B01A83.3060501@armiento.net> <1AC114B9-DB82-4F97-B0A8-831233CA2ECE@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1AC114B9-DB82-4F97-B0A8-831233CA2ECE@gmx.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Joachim Henke wrote: > Currently the Linux kernel simply uses monitor/mwait as a faster > 'hlt' replacement, so it should be "safe" there. I don't know about > other guest OSs. Anyway, I proposed this hack only as a quick > "solution" for local usage. As long as there's only one CPU and 'mwait' isn't used to wait for a _device_ writing to memory, then giving it the same behaviour as 'hlt' will be fine. In that case, the only way the memory could be written is as a result of an interrupt, which wakes 'hlt' too. If there's more than one CPU, or the OS uses 'mwait' to wait for a device writing to memory, then you can emulate it accurately by trapping access to the page containing the waited-on location(s) using the MMU, although the performance may or may not be adequate. -- Jamie