From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark McLoughlin Subject: Re: Loss of lock drop in qemu/net.c Date: Wed, 17 Dec 2008 09:19:23 +0000 Message-ID: <1229505563.3685.37.camel@localhost.localdomain> References: <4948039B.7060400@redhat.com> Reply-To: Mark McLoughlin Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , kvm-devel To: Avi Kivity Return-path: Received: from mx2.redhat.com ([66.187.237.31]:56262 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757586AbYLQJT3 (ORCPT ); Wed, 17 Dec 2008 04:19:29 -0500 In-Reply-To: <4948039B.7060400@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, 2008-12-16 at 21:38 +0200, Avi Kivity wrote: > The recent qemu merged does not allow net.h to include kvm code (due to > a dependency on cpu.h). This means I had to drop the > kvm_sleep_begin()/kvm_sleep_end() around the packet send (which, btw, > makes the whole thing vulnerable to hotunplug; we need refcounting or > locking here). How can the tap vlan client be affected by hotunplug? (Dropping the lock from a hotunpluggable PCI device like virtio_net would be dangerous - even though the removal is done by the monitor in the I/O thread and so can't happen while the thread is sleeping, the device isn't actually removed until the guest has acked it with EJ0 and this would be handled by a vcpu thread) Cheers, Mark.