Re: Can I xc_await_suspend() for a suspend event caused by another application?

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 10/08/15 10:28, Razvan Cojocaru wrote:
>> I've noticed that the xc_suspend_evtchn_init() functions in xenguest.h
>> connect the client application to a guest suspend event channel, and
>> that it's possible to subscribe to these events, in theory even if you
>> never signal the channel (i.e. even if you don't issue a suspend request).
>>
>> But all the in-tree examples I've read seem to first signal the channel
>> and then wait on the same channel for the confirmation that the guest is
>> suspending.
>>
>> Can the event channel be used solely to inform a monitoring application
>> that _another_ application (for example, xl) has requested a suspend?
> Looking at the code and what documentation I could find, it turns out
> that not only xc_suspend_evtchn_init() has not been designed to do what
> I am after, but it additionally only works for (some) PV guests.
>
> I've also looked into monitoring writes to ~/control/shutdown, but that
> of course also only applies to PV domains.
>
> What I need is to be able to know that any domain (but mostly HVMs) is
> about to be suspended, so that I can do some hooks cleanup in the guest
> while it's still running, and I'm looking for a way to do that without
> modifying Xen at all, otherwise I'd need to send out a new kind of
> vm_event or something similar, and obviously simpler is better. Could
> maybe someone kindly point out a reliable way to do that with the
> current Xen code, if it exists and I just haven't been able to find it?

What point of suspend do you need to be before?

Hooking the actual point of suspend is quite easy - hook
SCHEDOP_shutdown (for domains doing PV suspend themselves) and
SCHEDOP_remote_shutdown (for qemu suspending a guest on behalf of a non
PV action).

Off the top of my head, the following methods of starting a suspend from
outside of the guest are:

* ~/control/shutdown, but a guest (including PV aware HVM) can ignore this
* ~/control/sysrq, to send a sysrq key
* Inject an ACPI "power button" or "lid closed" GPE, but neither of
these might result in suspend.

Furthermore, hooking those doesn't catch an internal attempt to suspend.

I think your best bet is to actually hook the suspend/shutdown path
inside the guest.

~Andrew