From: Richard Zidlicky <rz@linux-m68k.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Qemu workstation
Date: Wed, 7 Apr 2004 19:50:22 +0200 [thread overview]
Message-ID: <20040407175022.GB4629@linux-m68k.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0404071035240.10871@alpha.polcom.net>
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
next prev parent reply other threads:[~2004-04-08 19:47 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-05 8:47 [Qemu-devel] Qemu workstation Jean-Michel POURE
2004-04-05 9:10 ` John R. Hogerhuis
2004-04-05 9:30 ` Rudi Lippert
2004-04-05 9:55 ` Jean-Michel POURE
2004-04-05 19:31 ` Fabrice Bellard
2004-04-05 21:49 ` Jamie Burns
2004-04-06 12:17 ` Richard Zidlicky
2004-04-06 13:28 ` Brad Campbell
2004-04-06 20:23 ` Filip Navara
2004-04-07 4:34 ` Brad Campbell
2004-04-07 7:59 ` Filip Navara
2004-04-07 8:24 ` Brad Campbell
2004-04-07 8:47 ` Grzegorz Kulewski
2004-04-07 17:50 ` Richard Zidlicky [this message]
2004-04-07 9:40 ` Filip Navara
2004-04-06 14:00 ` Jamie Burns
2004-04-06 19:00 ` Fabrice Bellard
2004-04-05 9:38 ` Jean-Michel POURE
2004-04-05 10:23 ` John R. Hogerhuis
-- strict thread matches above, loose matches on Subject: below --
2004-04-05 15:19 Mike Nordell
2004-04-05 20:40 ` Filip Navara
2004-04-05 21:05 ` John R. Hogerhuis
2004-04-05 21:15 ` Filip Navara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040407175022.GB4629@linux-m68k.org \
--to=rz@linux-m68k.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.