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

[Anthony Liguori <anthony@codemonkey.ws>]

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