From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30)
	id 1BBfVB-0000HJ-My
	for qemu-devel@nongnu.org; Thu, 08 Apr 2004 15:47:53 -0400
Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30)
	id 1BBfUH-0006ox-NO
	for qemu-devel@nongnu.org; Thu, 08 Apr 2004 15:47:29 -0400
Received: from [213.191.74.84] (helo=mx2.ngi.de)
	by monty-python.gnu.org with esmtp (Exim 4.30) id 1BBfUH-0006n5-3V
	for qemu-devel@nongnu.org; Thu, 08 Apr 2004 15:46:57 -0400
Received: from unknown (HELO rz.zidlicky.org) ([217.185.113.243])
	(envelope-sender <rz@linux-m68k.org>)
	by 0 (qmail-ldap-1.03) with SMTP
	for <qemu-devel@nongnu.org>; 8 Apr 2004 18:29:45 -0000
Date: Wed, 7 Apr 2004 19:50:22 +0200
From: Richard Zidlicky <rz@linux-m68k.org>
Subject: Re: [Qemu-devel] Qemu workstation
Message-ID: <20040407175022.GB4629@linux-m68k.org>
References: <1081156203.3939.10.camel@aragorn> <4071B41F.3040201@bellard.org>
	<001601c41b57$ed1704f0$6407a8c0@shaggy>
	<20040406121738.GC2774@linux-m68k.org>
	<4072B070.3060700@wasp.net.au> <407311D8.5020403@volny.cz>
	<407384DE.4020900@wasp.net.au>
	<7992c6b079c0068519527b855dde759e@www3.mail.volny.cz>
	<4073BAAC.5070904@wasp.net.au>
	<Pine.LNX.4.58.0404071035240.10871@alpha.polcom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58.0404071035240.10871@alpha.polcom.net>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://mail.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://mail.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://mail.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

On Wed, Apr 07, 2004 at 10:47:26AM +0200, Grzegorz Kulewski wrote:
> On Wed, 7 Apr 2004, Brad Campbell wrote:
> 
> > Filip Navara wrote:
> > > Brad Campbell wrote:
> > > 
> > >>How does that work then?
> > > 
> > > 
> > > I don't know the exact details.
> > > 
> > > 
> > >>I have some code that uses a NOP loop for accurate
> > >>timing? That spins at 100% cpu usage, how does a 
> > >>NOP tell the processor to idle? HLT does.
> > > 
> > > 
> > > HLT instruction halts the CPU so no more instructions are
> > > processed and the CPU freezes. That's usable only in situation
> > > like Windows blue screens.
> > 
> > It does? My information tells me that it halts the processor until an interrupt or other wakeup 
> > source occurs. Check arch/i386/kernel/process.c
> > 
> > /*
> >   * We use this if we don't have any better
> >   * idle routine..
> >   */
> > void default_idle(void)
> > {
> >          if (current_cpu_data.hlt_works_ok && !hlt_counter) {
> >                  __cli();
> >                  if (!current->need_resched)
> >                          safe_halt();
> >                  else
> >                          __sti();
> >          }
> > }
> > 
> > and in include/asm/system.h
> > 
> > system.h:#define safe_halt()            __asm__ __volatile__("sti; hlt": : :"memory")
> > 
> > Looks like a hlt to me and not a nop in site.
> > The kernel does a check at boot time to see if the processor supports the hlt instruction and if it 
> > does it uses that in the idle loop.
> > 
> > Am I wrong?
> 
> You are right.
> 
> HLT will block only until interrupt arrives. And there is at least clock 
> interrupt from time to time.

.. anyone remembers the Pentium(tm) "halt" bug ? How should QEMU
emulate that ?;)

it is easy when the guest OS uses hlt of course but a brief look
at some Linux kernel sources suggests there are a few more methods
to do it. Well x86 assembly was never my strong point.

Richard