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

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

On 08/10/2015 12:52 PM, Andrew Cooper wrote:
> 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.

Thanks for the reply! I haven't been clear, sorry - it's not the guest
that I need to be aware of a suspend beforehand, but the monitoring
application that lives in dom0 or a similarly privileged domain.

When xl, or XenCenter via XAPI, issues a request that results in a guest
suspend (for example, 'xl save'), I'd like the monitoring application
(the one doing introspection, subscribed to vm_events) to be able to
know while the guest is still running, so that it can have a chance to
do some cleanup specific to this case.

The way I do it now, I've subscribed to @releaseDomain xenstore events,
but when these come the guest has already become history. This is good
enough for "regular" guest shutdowns, but it gets trickier with 'xl
save'-type scenarios.

So the question is, basically, is there currenly a way for a dom0
application to know that somebody issued 'xl save' on an interesting
guest, via xenstore or some other mechanism, _before_ @releaseDomain
comes (i.e. while the guest is still alive)?


Thanks,
Razvan