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

[Michael S. Tsirkin]

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