[Qemu-devel] Re: [PATCH] net: delay peer host device delete

["Michael S. Tsirkin" <mst@redhat.com>]

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

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?

So why can't we let management do netdev_del and have it take effect
when this becomes possible?

> You're trying to come up with a workaround for the fact that libvirt
> is making bad assumptions.

BTW, even if it is, I don't think we should be crashing qemu or guest.

> 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.
> 

But frankly, most command semantics are completely ad hock and not well
undefined, in my mind it's better to define them to accomodate existing
users.

-- 
MST