[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Can I xc_await_suspend() for a suspend event caused by another application?


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  • Date: Mon, 10 Aug 2015 13:03:39 +0300
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Mon, 10 Aug 2015 10:02:39 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=k+/r9QXJOCLgTRPd+n0jF6JVaB4CUDfSTWHg8TfPUQsdLAExsjS9Co4X9lagSEBKd+N81siplJyTTLlvCsMsb8+ZUKUfhYq6xL3dZwkQ0h6OWyXUDkVULNq3VXOZ72NxOGZd6b9Av6bmiG6SikMonrLVoY3+eDKd9GFUePSrSkg9TY/RvMi4pK2kJ5nXj+4tm3KqnD3Vfxodt/iHc3E/kXrvkP1WK5rPu68tg/5Rr8h1E0bSYtlWlDNiZWQwI/5lSLwC+VQeBiq6KHP02fUs812JOt4jLQUvpH3SHbmntqUGjaRYk21FxcA/zbb8Up1Q/eHjQ57BV5N9ZU/vPTXbkQ==; h=Received:Received:Received:Received:Received:From:Subject:To:References:X-Enigmail-Draft-Status:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.