Re: [Qemu-devel] [PATCH] qom: removal of link property need to release its target

[Anthony Liguori <anthony@codemonkey.ws>]

Paolo Bonzini <pbonzini@redhat.com> 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