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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).