From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51340 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OxzAP-0006Qz-9L for qemu-devel@nongnu.org; Tue, 21 Sep 2010 05:29:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oxz6s-0005pb-VB for qemu-devel@nongnu.org; Tue, 21 Sep 2010 05:26:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63022) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oxz6s-0005pW-NU for qemu-devel@nongnu.org; Tue, 21 Sep 2010 05:25:58 -0400 Date: Tue, 21 Sep 2010 11:20:00 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: [PATCH] net: delay peer host device delete Message-ID: <20100921092000.GD4365@redhat.com> References: <4C978EC9.20907@codemonkey.ws> <20100920164758.GB29862@redhat.com> <4C979258.9020701@codemonkey.ws> <20100920171439.GF29862@redhat.com> <4C97A474.8040900@codemonkey.ws> <4C97A5C4.7040205@codemonkey.ws> <20100920185913.GF30611@redhat.com> <4C97B46A.6020909@codemonkey.ws> <20100920193716.GJ30611@redhat.com> <20100921085814.GC28304@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100921085814.GC28304@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org On Tue, Sep 21, 2010 at 09:58:14AM +0100, Daniel P. Berrange wrote: > On Mon, Sep 20, 2010 at 09:37:16PM +0200, Michael S. Tsirkin wrote: > > On Mon, Sep 20, 2010 at 02:22:18PM -0500, Anthony Liguori wrote: > > > On 09/20/2010 01:59 PM, Michael S. Tsirkin wrote: > > > >>You can also initiate the unplug from the OS without the ACPI event > > > >>ever happening. I suspect that in our current implementation, that > > > >>means that we'll automatically delete the device which may have > > > >>strange effects on management tools. > > > >> > > > >>So it probably makes sense for our interface to present the same > > > >>procedure. What do you think? > > > >> > > > >>Regards, > > > >> > > > >>Anthony Liguori > > > >We seem to have two discussions here. you speak about how an ideal hot plug > > > >interface will look. This can involve new commands etc. > > > >I speak about fixing existing ones so qemu and/or guest won't crash. > > > > > > To be fair, existing qemu won't crash if you do: > > > > > > (qemu) device_del > > > Use info_qtree to notice when device goes away > > > (qemu) netdev_del > > > > Asking libvirt to busy loop polling the monitor sounds like a really bad > > situation: note that guest is blocked from doing any io while monitor is > > used, so it may in fact prevent it from making progress. Right? > > Clearly we need either an async command completion, or an async > event notification of device_del. No one wants todo polling, > nor does anyone sane want to try to parse the outout of info > qtree :-) > > > > So why can't we let management do netdev_del and have it take effect > > when this becomes possible? > > That would be really unpleasant to deal with. netdev_del should > always kill the backend immediately, even if the frontend device > still exists. If this could cause issues for the frontend, then just > connect it to a no-op backend internally so it gets no further data. > In the context of drive_del, once it returns, libvirt changes the security > labelling, so QEMU is guarenteed not to be able to use the backend > anymore, even if it tries to. We would do the same for netdev_del if > we could. OK, that's clear enough. One note though: you won't be able to create another backend with the same name until the frontend is gone. -- MST