From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=35458 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Oxlyi-0006qs-5o
	for qemu-devel@nongnu.org; Mon, 20 Sep 2010 15:24:41 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1Oxlwi-00070f-3j
	for qemu-devel@nongnu.org; Mon, 20 Sep 2010 15:22:37 -0400
Received: from mail-vw0-f45.google.com ([209.85.212.45]:58637)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1Oxlwi-00070b-1c
	for qemu-devel@nongnu.org; Mon, 20 Sep 2010 15:22:36 -0400
Received: by vws19 with SMTP id 19so3844269vws.4
	for <qemu-devel@nongnu.org>; Mon, 20 Sep 2010 12:22:35 -0700 (PDT)
Message-ID: <4C97B46A.6020909@codemonkey.ws>
Date: Mon, 20 Sep 2010 14:22:18 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <20100920163042.GA29466@redhat.com> <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>
In-Reply-To: <20100920185913.GF30611@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH] net: delay peer host device delete
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org

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 <device>
Use info_qtree to notice when device goes away
(qemu) netdev_del <backend>

You're trying to come up with a workaround for the fact that libvirt is 
making bad assumptions.  That's wrong.  We either need to fix libvirt to 
not make bad assumptions or we need to provide better interfaces for 
libvirt to use if the current interfaces aren't desirable.

Regards,

Anthony Liguori

> This requires fixing existing commands, unless we can't
> fix them at all - which is demonstrably not the case.
>