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

[Michael S. Tsirkin]

On Mon, Sep 20, 2010 at 03:20:59PM -0500, Anthony Liguori wrote:
> On 09/20/2010 02:44 PM, Michael S. Tsirkin wrote:
> >
> >>I think the only workable approach that doesn't involve new commands
> >>is to change the semantics of the existing ones.
> >>
> >>Make netdev_del work regardless of whether the device is still present.
> >>
> >>You would need to reference count the actual netdev structure and
> >>have each device using it unref on delete.  You make netdev_del mark
> >>the device as deleted and when a device is deleted, any calls into
> >>the device effectively become nops.
> >>
> >>You have to go through most of the cleanup process to ensure that
> >>tap device gets closed even before your reference count goes to
> >>zero.
> >I think you mean 'does not get closed': we need the fd to get the flags etc.
> 
> No, I actually meant does get closed.
> 
> When you do netdev_del, it should result in the fd getting closed.
> 
> The actual netdev structure then becomes a zombie that's completely
> useless until the device goes away.
> 
> >Note that it will mostly work unless when it'll crash.
> >Issue is we don't have any documentation so
> >people get the command set by trial and error.
> >
> >So how can we prove it's a user bug and not qemu bug?
> >I guess we should blame ourselves until proven innocent.
> 
> Here's what I'm now suggesting:
> 
> device_del -> may or may not unplug a device from a guest when it
> returns.  To figure out if it does, you have to run info qdm.

I think it should also always unplug on guest reset.

> netdev_del -> always destroys a netdev device when it returns.  May
> be called at any point in time.  If you destroy a netdev while the
> device is still using it, all packets go into the bit bucket and the
> link status is modified to be unplugged.

One issue here is that we can't allow a new device with same name
to be created until the nic is destroyed.

> You're suggesting:
> 
> netdev_del -> may or may not destroy a netdev depending on when the
> device delete completes.  Eventually, when there's a reset, we will
> kill the device.  Even though the netdev is still active, we'll hide
> it from the management tools.

This last point is a bug in my patch. I now think we should not hide it,
run info net to figure out when it is removed.

> I think the suggested semantics are totally unusable.  If we can
> make something deterministic for a management tool, that should be
> the path we take.
> 
> Regards,
> 
> Anthony Liguori

So I basically propose that netdev_del and device_del behave
identically. Why is this unusable?


-- 
MST