The reason of using Qcow images to boot smp Windows fail ?

The reason of using Qcow images to boot smp Windows fail ?

[Liu, Eric E]

Hi Avi
	For current commit Windows SMP guests will fail to boot if using
Qcow images based on the original backend file on a remote network file
system.  I found out that one Ap thread is hang at the place of
bdrv_read_em() -> qemu_aio_wait() -> sigwait(), which is waiting for the
signal SIGUSR2. Since AIO thread sends a SIGUSR2 to QEMU to indicate the
completion of an AIO request, and if we use Qcow img, it will wait for
the signal. In current code we don't mask the signal SIGUSR2 in VCPU0 's
thread, so it may eat the signal the Ap thread is waiting for. if I mask
the signal as fellow: 

  1 diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
  2 index 9aee903..9fe4235 100644
  3 --- a/qemu/qemu-kvm.c
  4 +++ b/qemu/qemu-kvm.c
  5 @@ -310,9 +310,10 @@ static void setup_kernel_sigmask(CPUState *env)
  6
  7      sigprocmask(SIG_BLOCK, NULL, &set);
  8      sigdelset(&set, SIG_IPI);
  9 -    if (env->cpu_index == 0)
 10 +    if (env->cpu_index == 0) {
 11         sigandset(&set, &set, &io_negsigset);
 12 -
 13 +       sigaddset(&set, SIGUSR2);
 14 +    }
 15      kvm_set_signal_mask(kvm_context, env->cpu_index, &set);
 16  }

 Windows SMP guests will boot successfully. I am not very clear that why
we don't mask it, do you have other consideration? thx.

--Eric (Liu, Feng)

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: The reason of using Qcow images to boot smp Windows fail ?

[Avi Kivity]

Liu, Eric E wrote:
> Hi Avi
> 	For current commit Windows SMP guests will fail to boot if using
> Qcow images based on the original backend file on a remote network file
> system.  I found out that one Ap thread is hang at the place of
> bdrv_read_em() -> qemu_aio_wait() -> sigwait(), which is waiting for the
> signal SIGUSR2. Since AIO thread sends a SIGUSR2 to QEMU to indicate the
> completion of an AIO request, and if we use Qcow img, it will wait for
> the signal. In current code we don't mask the signal SIGUSR2 in VCPU0 's
> thread, so it may eat the signal the Ap thread is waiting for. if I mask
> the signal as fellow: 
>
>   1 diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
>   2 index 9aee903..9fe4235 100644
>   3 --- a/qemu/qemu-kvm.c
>   4 +++ b/qemu/qemu-kvm.c
>   5 @@ -310,9 +310,10 @@ static void setup_kernel_sigmask(CPUState *env)
>   6
>   7      sigprocmask(SIG_BLOCK, NULL, &set);
>   8      sigdelset(&set, SIG_IPI);
>   9 -    if (env->cpu_index == 0)
>  10 +    if (env->cpu_index == 0) {
>  11         sigandset(&set, &set, &io_negsigset);
>  12 -
>  13 +       sigaddset(&set, SIGUSR2);
>  14 +    }
>  15      kvm_set_signal_mask(kvm_context, env->cpu_index, &set);
>  16  }
>
>  Windows SMP guests will boot successfully. I am not very clear that why
> we don't mask it, do you have other consideration? thx.
>
>   

The intent was that vcpu 0 will handle all I/O and timers, simply to be 
similar to regular qemu.  But as you say, this breaks aio, so we should 
remove SIGUSR2 from io_sigset and io_negsigset and enable it like SIG_IPI.

Longer term I'd like to move network I/O and alarm handling to a 
separate thread to reduce vmexits, but that's a separate issue.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace