From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33655 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OxmtJ-0000oO-2O for qemu-devel@nongnu.org; Mon, 20 Sep 2010 16:23:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oxmrc-0006mm-28 for qemu-devel@nongnu.org; Mon, 20 Sep 2010 16:21:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46034) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oxmrb-0006ma-Om for qemu-devel@nongnu.org; Mon, 20 Sep 2010 16:21:24 -0400 Date: Mon, 20 Sep 2010 22:15:24 +0200 From: "Michael S. Tsirkin" Message-ID: <20100920201524.GA760@redhat.com> References: <4C978EC9.20907@codemonkey.ws> <20100920164758.GB29862@redhat.com> <4C979258.9020701@codemonkey.ws> <20100920171439.GF29862@redhat.com> <4C97A474.8040900@codemonkey.ws> <4C97A5C4.7040205@codemonkey.ws> <20100920185913.GF30611@redhat.com> <4C97B46A.6020909@codemonkey.ws> <20100920193716.GJ30611@redhat.com> <4C97C0F1.9040201@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C97C0F1.9040201@codemonkey.ws> Subject: [Qemu-devel] Re: [PATCH] net: delay peer host device delete List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori , berrange@redhat.com Cc: qemu-devel@nongnu.org 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 > >>Use info_qtree to notice when device goes away > >>(qemu) netdev_del > >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