Re: [Qemu-devel] [PATCH] monitor: Add force option support to pci_del command

[Luiz Capitulino <lcapitulino@redhat.com>]

On Tue, 15 Jun 2010 11:03:13 +0200
Markus Armbruster <armbru@redhat.com> wrote:

> Anthony Liguori <anthony@codemonkey.ws> 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.