From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4Jb7-00027u-Gi for qemu-devel@nongnu.org; Wed, 22 Aug 2012 18:40:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T4Jb6-0007XG-Cp for qemu-devel@nongnu.org; Wed, 22 Aug 2012 18:40:25 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:38209) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4Jb6-0007X2-7x for qemu-devel@nongnu.org; Wed, 22 Aug 2012 18:40:24 -0400 Received: by obbta14 with SMTP id ta14so239244obb.4 for ; Wed, 22 Aug 2012 15:40:23 -0700 (PDT) From: Anthony Liguori In-Reply-To: <503556B8.3040109@redhat.com> References: <1345604562-27289-1-git-send-email-qemulist@gmail.com> <5034CA4C.7020706@redhat.com> <877gsqlw96.fsf@codemonkey.ws> <5035475A.5070409@redhat.com> <87628a4nb1.fsf@codemonkey.ws> <503556B8.3040109@redhat.com> Date: Wed, 22 Aug 2012 17:40:21 -0500 Message-ID: <87mx1mo8iy.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH] qom: removal of link property need to release its target List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Liu Ping Fan , Liu Ping Fan , qemu-devel@nongnu.org Paolo Bonzini writes: > Il 22/08/2012 23:41, Anthony Liguori ha scritto: >> >> (1) should drop the floating reference and the reference held by the >> container. That's what I meant by calling object_unparent in >> qmp_device_del. >> >> (2) should simply remove the device from the bus (further releasing a >> reference). >> >> (3) would happen automatically from (1) and (2) if they were called in >> that order. >> >> If the guest instantiates a remove on it's own, the device would be >> disconnected from the bus (functionally unplugged) but still in the >> container so it would *not* go away. >> >> I think this is desirable behavior. > > It may be (I'm not sure it is desirable for HMP), but it's also > backwards-incompatible. Right now, an unrequested guest-initiated > remove causes the device to disappear in "info qtree" too. info qtree doesn't print out the composition tree, it prints the sysbus tree. Once the parent bus is set to NULL, it won't show on info qtree anymore. > So, for > backwards-compatibility we need to keep using object_delete after > setting the parent bus to NULL. > > WRT adding the unparent *also* in qmp_device_del, that prevents you from > later doing a surprise removal via the monitor, because you don't have > anymore a way to refer the device. I'm also worried of what happens if > an object loses its canonical path in the middle of its life... I need to think more about this I guess.. What I'm after is an interface that consists of: 1) orphan device <- i don't care about this device anymore, as soon as you can, get rid of it 2) request unplug <- ask the guest to remove the device 3) guest eject <- ejects a device from the guest device_del would consist of "orphan device" followed by "request unplug". I don't really like the notion of a "forced eject" where we delete a device when the guest is using it and not cooperative. I don't see the benefit at all. Forcing detachment of a BlockDriverState from a device followed by EIO being reported to the guest for all I/O ops makes sense to me. But not forced removal of virtio-blk-pci. Regards, Anthony Liguori > > I'm not sure object_unparent should be extern, even. > > Paolo