From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: The reason of using Qcow images to boot smp Windows fail ? Date: Tue, 08 Jan 2008 12:04:30 +0200 Message-ID: <47834AAE.1090806@qumranet.com> References: <9D7649D18729DE4BB2BD7B494F7FEDC2D052E8@pdsmsx415.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: "Liu, Eric E" Return-path: In-Reply-To: <9D7649D18729DE4BB2BD7B494F7FEDC2D052E8-wq7ZOvIWXbMAbVU2wMM1CrfspsVTdybXVpNB7YpNyf8@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org 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