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
