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

[Michael S. Tsirkin]

On Mon, Sep 20, 2010 at 03:15:45PM -0500, Anthony Liguori wrote:
> 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


Agreed. Any libvirt guys listening in on this discussion
and have an opinion on what does libvirt actually want?

-- 
MST