From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33856 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OxmtY-00018x-FM for qemu-devel@nongnu.org; Mon, 20 Sep 2010 16:23:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OxmmO-0005xl-FA for qemu-devel@nongnu.org; Mon, 20 Sep 2010 16:16:01 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:40328) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OxmmO-0005xc-Ch for qemu-devel@nongnu.org; Mon, 20 Sep 2010 16:16:00 -0400 Received: by vws19 with SMTP id 19so3905555vws.4 for ; Mon, 20 Sep 2010 13:15:59 -0700 (PDT) Message-ID: <4C97C0F1.9040201@codemonkey.ws> Date: Mon, 20 Sep 2010 15:15:45 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20100920163042.GA29466@redhat.com> <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> In-Reply-To: <20100920193716.GJ30611@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org 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