From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43310 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPJd5-0005ZN-G0 for qemu-devel@nongnu.org; Thu, 17 Jun 2010 14:15:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPJd4-0002u7-3w for qemu-devel@nongnu.org; Thu, 17 Jun 2010 14:15:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49578) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPJd3-0002tv-SQ for qemu-devel@nongnu.org; Thu, 17 Jun 2010 14:15:54 -0400 Date: Thu, 17 Jun 2010 15:15:43 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH] monitor: Add force option support to pci_del command Message-ID: <20100617151543.562ba3e1@redhat.com> In-Reply-To: References: <4C0F450B.5000802@redhat.com> <4C0FA4B9.7090906@redhat.com> <4C16600A.4030208@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Marcos Oviedo , Gerd Hoffmann , qemu-devel@nongnu.org On Tue, 15 Jun 2010 11:03:13 +0200 Markus Armbruster wrote: > Anthony Liguori writes: > > > On 06/09/2010 09:27 AM, Gerd Hoffmann wrote: > >> Hi, > >> > >>> This make sense when you mistakenly add a pci device on a -s -S > >>> scenario, like the scenario described on the following bug: > >>> https://bugs.launchpad.net/qemu/+bug/544367. > >> > >> It doesn't IMHO. > >> > >>> When ACPI-based hotplug support is present on the guest and we run > >>> pci_del with the force option, the hotplug events will still be > >>> generated to the guest and the guest still will trigger the EJx event, > >>> which will end by calling pciej_write() on qemu side. This function will > >>> do nothing on a -f and pci hotplug support scenario, as the pci device > >>> was previously removed by pci_del. > >> > >> And in case the guest wants to do anything (like flushing dirty > >> buffers) before triggering the EJx event it will horribly fail. > >> > >> If the guest is stopped while unplugging the device the unplug > >> should happen as soon as the guest is unpaused. > > > > This is a case where the fundamental problem is that the pci_del > > command should block until the guest has actually responded to the > > request. > > > > pci_del returning with no error and yet not having the operation > > complete is certainly a usability issue. > > s/pci_del/device_del/g :) > > What should device_del do? Wait until ACPI reports that the guest has > processed the unplug event? What if the guest doesn't? Hanging > indefinitely is not an option. Can we reliably detect this case? This is a general question for all commands that can take way too long or never return. For QMP the question is whether we should handle this in QEMU or in the client. Ie, if the guest doesn't respond the client could detect that and cancel the async command. For HMP we could just live with that or suspend the shell and allow the user to cancel the operation (eg. ctrl+c) and the obvious alternative is to have timeouts, allowing the user to set them.