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

[Anthony Liguori]

On 09/20/2010 02:37 PM, 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?
>    

With a busy loop?  No, the guest will always make some progress because 
we drop back to the main loop.  But that's besides the point really.  
libvirt can just do a usleep() when polling.

Yes, this interface sucks but that's the interface we have today.

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

You're making netdev_del be a semantic request that a network backend is 
eventually deleted after some guest controlled period of time.

If libvirt is trying to do useful things like manage a limit set of 
resources (maybe VFs using SR-IOV passthrough), then libvirt needs to 
know when it can reassign a VF to another guest.  But now it can't do 
that after it does netdev_del.  Is it supposed to poll to figure out 
when it can do it?

> > 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 certainly true.  But that's a different patch.

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

Okay, let's give them an interface they actually want.  Forcing them to 
poll for when a netdev is actually removed is probably not what they 
actually want.

Regards,

Anthony Liguori