From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46681 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOPPm-0006wM-7e for qemu-devel@nongnu.org; Tue, 15 Jun 2010 02:14:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOPPk-0007d4-F9 for qemu-devel@nongnu.org; Tue, 15 Jun 2010 02:14:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46136) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOPPk-0007cw-7u for qemu-devel@nongnu.org; Tue, 15 Jun 2010 02:14:24 -0400 Date: Tue, 15 Jun 2010 07:14:19 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH] stop cpus before forking. Message-ID: <20100615061419.GA521@redhat.com> References: <1276543644-32689-1-git-send-email-glommer@redhat.com> <4C1683EC.3010609@codemonkey.ws> <20100614194237.GD19104@mothafucka.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100614194237.GD19104@mothafucka.localdomain> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, avi@redhat.com On Mon, Jun 14, 2010 at 04:42:37PM -0300, Glauber Costa wrote: > On Mon, Jun 14, 2010 at 02:33:00PM -0500, Anthony Liguori wrote: > > On 06/14/2010 02:27 PM, Glauber Costa wrote: > > >This patch fixes a bug that happens with kvm, irqchip-in-kernel, > > >while adding a netdev. Despite the situations of reproduction being > > >specific to kvm, I believe this fix is pretty generic, and fits here. > > >Specially if we ever want to have our own irqchip in kernel too. > > > > > >The problem happens after the fork system call, and although it is not > > >100 % reproduceable, happens pretty often. After fork, the memory where > > >the apic is mapped is present in both processes. It ends up confusing > > >the vcpus somewhere in the irq<-> ack path, and qemu hangs, with no > > >irqs being delivered at all from that point on. > > > > > >Making sure the vcpus are stopped before forking makes the problem go > > >away. Besides, this is a pretty unfrequent operation, which already hangs > > >the io-thread for a while. So it should not hurt performance. > > > > > >Signed-off-by: Glauber Costa > > > > This doesn't make very much sense to me but smells like a kernel bug to me. > My interpretation is that by doing that, we make sure no in-flight > requests are happening. Actually, a sleep(x), with x sufficiently big > is enough to make this problem go away, but that is too hacky. > > I do agree that this is most likely a kernel bug. But as with any other > kernel bugs, I believe this is a easy workaround to have things working > even in older kernels until we fix it. > > > > > Even if it isn't, I can't rationalize why stopping the vm like this > > is enough to fix such a problem. Is the problem that the KVM VCPU > > threads get duplicated while potentially running or something like > > that? > > I doubt fork is duplicating the vcpu threads. More than that, this > bug does not happen with userspace irqchip. Hmm, could this problem be hitting other places where we fork() besides the netdev helper script ? I have seen a intermittent bug[1] with migration, where using exec: migration will freeze the entire guest and setting -no-kvm-irqchip fixes the problem Regards, Daniel [1] https://bugzilla.redhat.com/show_bug.cgi?id=585195 -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|