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

[Anthony Liguori]

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.

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.

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.

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