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

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

[Razvan Cojocaru]

Hello,

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?

To give you some context, I'm interested in being able to make the
difference between the case when a guest is going into suspend mode (and
is still running), and the case when a guest is history (which I'm now
doing via @releaseDomain xenstore events). Basically, the difference
between a regular guest shutdown and what happens on "xl save" (as early
as possible, while the guest is still running).


Thanks,
Razvan

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

[Razvan Cojocaru]

> 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?


Thanks,
Razvan

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

[Andrew Cooper]

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

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

[Razvan Cojocaru]

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