From: Marcelo Tosatti <mtosatti@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
Jan Kiszka <jan.kiszka@web.de>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Re: [PATCH] fix halt emulation with icount and CONFIG_IOTHREAD (v2)
Date: Thu, 17 Feb 2011 01:15:38 -0200 [thread overview]
Message-ID: <20110217031538.GA22552@amt.cnet> (raw)
In-Reply-To: <4D5B99A9.1010404@redhat.com>
On Wed, Feb 16, 2011 at 10:32:25AM +0100, Paolo Bonzini wrote:
> On 02/15/2011 09:56 PM, Marcelo Tosatti wrote:
> >Note: to be applied to uq/master.
> >
> >In icount mode, halt emulation should take into account the nearest
> >event when sleeping.
>
> I agree with Jan that this patch is not the best solution, if not incorrect.
>
> However, in the iothread, the main loop can kick the VCPU thread
> instead of running cpu_exec_all like it does in non-iothread mode.
> Something like this:
>
> diff --git a/vl.c b/vl.c
> index b436952..7835317 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1425,7 +1425,9 @@ static void main_loop(void)
> qemu_main_loop_start();
>
> for (;;) {
> -#ifndef CONFIG_IOTHREAD
> +#ifdef CONFIG_IOTHREAD
> + qemu_cpu_kick(first_cpu);
> +#else
> nonblocking = cpu_exec_all();
> if (vm_request_pending()) {
> nonblocking = true;
>
> I don't like this 100% because it relies on the fact that there is
> only one TCG execution thread. In a multithreaded world you would:
>
> 1) have each CPU register its own instruction counter;
>
> 2) have each CPU register its own QEMU_CLOCK_REALTIME timer based on
> qemu_icount_delta() and arm it just before going to sleep; the timer
> kicks the CPU.
>
> 3) remove all icount business from qemu_calculate_timeout.
>
> Item (3) is what makes me prefer my patch above (if it works) to
> Marcelo's. Marcelo's patch is tying even more
> qemu_calculate_timeout to the icount. So if anything, a patch
> tweaking the timedwait like Marcelo's should use something based on
> qemu_icount_delta().
Yes, using qemu_icount_delta directly in tcg_wait_io_event timedwait
is explicit (partially the reason for confusion with my patch).
So the reasoning for the patch is:
With icount vm_timer timers expire on virtual CPU time. If a CPU halts,
you cannot expect passage of realtime to trigger vm_timers expiration.
So instead vm_timer expiration is converted to realtime, and used as
halt timeout.
next prev parent reply other threads:[~2011-02-17 3:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-15 17:54 [Qemu-devel] [PATCH] fix halt emulation with icount and CONFIG_IOTHREAD Marcelo Tosatti
2011-02-15 18:58 ` [Qemu-devel] " Jan Kiszka
2011-02-15 20:04 ` Marcelo Tosatti
2011-02-15 20:33 ` Jan Kiszka
2011-02-15 20:55 ` Marcelo Tosatti
2011-02-15 20:56 ` [Qemu-devel] [PATCH] fix halt emulation with icount and CONFIG_IOTHREAD (v2) Marcelo Tosatti
2011-02-16 8:27 ` [Qemu-devel] " Jan Kiszka
2011-02-16 9:32 ` Paolo Bonzini
2011-02-16 9:46 ` Jan Kiszka
2011-02-16 9:57 ` Paolo Bonzini
2011-02-16 10:04 ` Jan Kiszka
2011-02-16 10:27 ` Paolo Bonzini
2011-02-16 10:34 ` Jan Kiszka
2011-02-16 11:05 ` Paolo Bonzini
2011-02-17 3:15 ` Marcelo Tosatti [this message]
2011-02-17 8:27 ` Paolo Bonzini
2011-02-18 17:13 ` Paolo Bonzini
2011-02-17 8:29 ` Jan Kiszka
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=20110217031538.GA22552@amt.cnet \
--to=mtosatti@redhat.com \
--cc=edgar.iglesias@gmail.com \
--cc=jan.kiszka@web.de \
--cc=pbonzini@redhat.com \
--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.