qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH] fix halt emulation with icount and CONFIG_IOTHR


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH] fix halt emulation with icount and CONFIG_IOTHREAD (v2)
Date: Wed, 16 Feb 2011 10:46:36 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2011-02-16 10:32, 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;

What should this be good for? The iothread already kicks the vcpu if it
wants to acquire the contended global mutex. And when the vcpu thread is
in halt state, kicking it should change no other state.

> 
> 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().

Really, that idle loop apparently does _nothing_ while
all_cpu_threads_idle is true. Or does the IPI signal handler apply some
magic? I still don't get what is supposed to be fixed in
qemu_tcg_wait_io_event.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]