Daniel Henrique Barboza <danielhb...@gmail.com> writes: > The qmp/hmp command 'system_wakeup' is simply a direct call to > 'qemu_system_wakeup_request' from vl.c. This function verifies if > runstate is SUSPENDED and if the wake up reason is valid before > proceeding. However, no error or warning is thrown if any of those > pre-requirements isn't met. There is no way for the caller to > differentiate between a successful wakeup or an error state caused > when trying to wake up a guest that wasn't suspended. > > This means that system_wakeup is silently failing, which can be > considered a bug. Adding error handling isn't an API break in this > case - applications that didn't check the result will remain broken, > the ones that check it will have a chance to deal with it. > > Adding to that, the commit before previous created a new QMP API called > query-current-machine, with a new flag called wakeup-suspend-support, > that indicates if the guest has the capability of waking up from suspended > state. Although such guest will never reach SUSPENDED state and erroring > it out in this scenario would suffice, it is more informative for the user > to differentiate between a failure because the guest isn't suspended versus > a failure because the guest does not have support for wake up at all. > > All this considered, this patch changes qmp_system_wakeup to check if > the guest is capable of waking up from suspend, and if it is suspended. > After this patch, this is the output of system_wakeup in a guest that > does not have wake-up from suspend support (ppc64): > > (qemu) system_wakeup > wake-up from suspend is not supported by this guest > (qemu) > > And this is the output of system_wakeup in a x86 guest that has the > support but isn't suspended: > > (qemu) system_wakeup > Unable to wake up: guest is not in suspended state > (qemu) > > Reported-by: Balamuruhan S <bal...@linux.vnet.ibm.com> > Signed-off-by: Daniel Henrique Barboza <danielhb...@gmail.com>
Reviewed-by: Markus Armbruster <arm...@redhat.com>
