Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Mirela Simonovic]

Hi Julien,


On Fri, Jan 26, 2018 at 5:08 PM, Julien Grall  wrote:
>
>
> On 24/01/18 17:55, Mirela Simonovic wrote:
>>
>> Hi Julien, Stefano,
>
>
> Hi Mirela,
>
>>
>> Thank you very much for the feedback!
>>
>>
>> On 01/11/2018 03:00 PM, Julien Grall wrote:
>>>
>>> Hi Mirela,
>>>
>>> Thank you for the sending the design document. The general design looks
>>> good to me. I have some comments below, but they are more related to the
>>> implementation of CPU on/off in Xen.
>>>
>>> On 22/12/17 17:41, Mirela Simonovic wrote:
>>>
>>> [...]
>>>
 +---
 +Resuming Guests
 +---
 +
 +Resume of the privileged guest (Dom0) is always following the Xen
 resume.
 +
 +An unprivileged guest shall resume once a device it owns triggers a
 wake-up
 +interrupt, regardless of whether Xen was suspended when the wake-up
 interrupt
 +was triggered. If Xen was suspended, it is assumed that Dom0 will be
 running
 +before the DomU guest starts to resume. The synchronization mechanism
 to
 +enforce the assumed condition is TBD.
>>>
>>>
>>> Given that all but the non-boot CPU will be offlined. Does the wake-up
>>> interrupt always need to target the non-boot CPU?
>>
>>
>> Wake-up interrupt needs to be targeted to the boot pCPU, and the resume
>> sequence has to start from the boot pCPU.
>
>
> I assume that wake-up interrupts could belong to a guest.
> In that case, the wake-up interrupts will need to be moved to the boot pCPU
> on suspend.
>
> [...]
>
>>>
>>> For instance, you likely need to migrate interrupts that was assigned to
>>> the physical CPU (either guest one or Xen one). Though Xen ones might be
>>> less a concern because I think they are always assigned to CPU0 at the
>>> moment.
>>
>>
>> I would very appreciate more information on this. These kind of scenarios
>> can be easily overlooked and I'm not that much experienced with pinning and
>> its side effects.
>> Lets assume a vCPU is pinned to the non-boot CPU#1. When the guest enables
>> an interrupt (interrupt is targeted to the vCPU), would Xen target physical
>> interrupt to the GIC CPU interface of pCPU#1 or pCPU#0 or all pCPUs?
>
>
> In your example, the interrupts will target pCPU#1 only.
>
>>
>>>
>>> Furthermore, PPI handlers are not removed. Same for any memory allocated
>>> (you may loose reference to it because percpu area for that CPU will get
>>> freed). I believe get into trouble when the CPU is back online?
>>
>>
>> Yes, I needed to add few fixes into existing code to enable pCPU to come
>> back online. I'll submit RFC soon.
>
>
> Thank you!
>
> [...]
>
>>>
>>> I may have miss other bits, so I would highly recommend to go through the
>>> boot code and see what could go wrong.
>>>
>>> [..]
>>>
 +Resume Flow
 +
 +The resume entry point shall be implemented in
 +* hyp_resume() in arch/arm/arm64/entry.S
 +The very beginning of the resume procedure has to be implemented in
 assembly.
 +It shall contain the following:
 +* Enable the MMU so that the structure containing CPU context which was
 saved on
 +suspend can be accessed
 +* Restore CPU context (to match the values saved on suspend) and return
 into C
 +* Set the system_state variable to SYS_STATE_resume
 +* Restore GIC context
 +* Resume timer
 +* Enable interrupts
 +* Enable non-boot CPUs by calling enable_nonboot_cpus()
>>>
>>>
>>> You would have to be careful on re-enabling the non-CPU. start_secondary
>>> is implemented based on the assumption that it will only be called during
>>> Xen boot. Some of the code may be part of __init (see cpu_up_send_sgi) or
>>> should not be called as it is after boot (e.g check_local_cpu_errata).
>>>
>>> Another I have in mind is the way VTCR_EL2 is set today (see
>>> setup_virt_paging). It is done at boot time, so if you online a CPU
>>> afterwards, VTCR_EL2 will not be set correctly.
>>
>>
>> Was there any reason to configure VTCR_EL2 after all CPUs become online?
>>
>> I fixed this as follows: in start_xen(), the boot CPU calls
>> setup_virt_paging() prior to enabling non-boot CPUs. setup_virt_paging()
>> configures VTCR_EL2 only for the boot CPU.
>> Non-boot CPUs call setup_virt_paging_one() later, from start_secondary().
>> Also, only the boot CPU performs the calculation for how to configure
>> VTCR_EL2, non-boot CPUs rely on the calculated value.
>
> This would not be correct. Imagine a platform with heterogeneous processors
> (such as big.LITTLE), each processors may have different set of "features"
> (e.g max IPA size supported). You want Xen to use a common set of "features"
> that would work on all CPUs.
>
> To give an example, your boot CPU may support maximum 48-bit IPA while all
> the other CPUs would support maximum 40-bit IPA. If Xen decides to use
> maximum 48-bit IPA, then page-tables would not work on other CPUs.
>
> In order to take the decision, you need to wait 

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Mirela Simonovic]

Hi Peng,

Sorry for late response, this email got buried and I accidentally saw it now.

On Thu, Apr 12, 2018 at 4:26 AM, Peng Fan <peng@nxp.com> wrote:
> Hi Edgar,
>
>> -Original Message-
>> From: Edgar E. Iglesias [mailto:edgar.igles...@xilinx.com]
>> Sent: 2018年3月26日 19:43
>> To: Peng Fan <peng@nxp.com>
>> Cc: Mirela Simonovic <mirela.simono...@aggios.com>; xen-de...@lists.xen.org;
>> sstabell...@kernel.org; julien.gr...@linaro.org
>> Subject: Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for
>> ARM
>>
>> On Mon, Mar 26, 2018 at 09:51:40AM +, Peng Fan wrote:
>> > Hi Mirela,
>> >
>> > Good to know that you are working suspend/resume support. Currently we
>> > are also trying to support this on i.MX8, just wonder do you have any
>> > open source available to support suspend to ram?
>> >

We don't have suspend to RAM support available in open source yet.
However, we are starting the upstream (just the first series covering
CPU hotplug is submitted so far).

>> > > +
>> > > +Suspend to RAM (in the following text 'suspend') for ARM in Xen
>> > > +should be coordinated using ARM PSCI standard [1].
>> > > +
>> > > +Ideally, EL1/2 should suspend in the following order:
>> > > +1) Unprivileged guests (DomUs) suspend
>> > > +2) Privileged guest (Dom0) suspends
>> > > +3) Xen suspends
>> > > +
>> > > +However, suspending unprivileged guests is not mandatory for
>> > > +suspending
>> > > +Dom0 and Xen. System suspend initiated by Dom0 (step 2) is
>> > > +considered to be an ultimate decision to suspend the physical
>> > > +machine. Suspending of Xen (step 3) is triggered whenever Dom0
>> > > +completes suspend. Xen suspend leads to the full suspend of EL2.
>> > > +
>> > > +If an unprivileged guest is not suspended at the moment when Dom0
>> > > +initiates its own suspend, the guest will be paused on Xen's
>> > > +suspend and unpaused on Xen's resume. That way, a guest which
>> > > +doesn't have power management support cannot prevent the physical
>> > > +system from suspending when the decision to suspend is made by
>> > > +privileged software
>> > > (Dom0).
>> > > +
>> > > +Each guest in the system is responsible for suspending the devices it 
>> > > owns.
>> > > +If a guest does not suspend a device, the device will continue to
>> > > +operate as it is configured at the moment when the system suspends.
>> > > +If a device triggers an interrupt while the physical system is
>> > > +suspended, the
>> > > system will resume.
>> > > +
>> > > +It is recommended for an unprivileged guest to participate in power
>> > > +management in the following scenario:
>> > > +Assume unprivileged guest owns a device which will trigger
>> > > +interrupt at some point. This interrupt will wake-up the system. If
>> > > +such a behavior is not wanted, coordination between Dom0 and the
>> > > +guest is required in order to inform the guest about the intended 
>> > > physical
>> system suspend.
>> > > +Then, the guest will have a chance to suspend the device or respond
>> > > +to the
>> > > request in an abort fashion.
>> > > +
>> > > +Since this proposal is focused on implementing PSCI-based suspend
>> > > +mechanisms in Xen, communication with or among the guests is not
>> > > +covered by
>> > > this document.
>> > > +The order of suspending the guests is assumed to be guaranteed by
>> > > +the software running in EL1.
>> > > +
>> > > +This document covers the following:
>> > > +1) Mechanism for suspending/resuming a guest:
>> > > + 1.1) Suspend is initiated by the guest
>> > > + 1.2) Resume is initiated by a device interrupt
>> > > +2) Mechanism for pausing/unpausing running guests when Dom0
>> > > +suspends
>> >
>> > Will this take care of passthroughed devices for DomU?
>>
>
> Thanks for your reply. Sorry for late reply
>
>> Hi Peng,
>>
>> The ZynqMP uses the EEMI Firmware interface to do power-management.
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.x
>> ilinx.com%2Fsupport%2Fdocumentation%2Fuser_guides%2Fug1200-eemi-api.p
>> df=02%7C01%7Cpeng.fan%40nxp.com%7C021307a245394e945cbf08d59
>> 30e

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Peng Fan]

Hi Edgar,

> -Original Message-
> From: Edgar E. Iglesias [mailto:edgar.igles...@xilinx.com]
> Sent: 2018年3月26日 19:43
> To: Peng Fan <peng@nxp.com>
> Cc: Mirela Simonovic <mirela.simono...@aggios.com>; xen-de...@lists.xen.org;
> sstabell...@kernel.org; julien.gr...@linaro.org
> Subject: Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for
> ARM
> 
> On Mon, Mar 26, 2018 at 09:51:40AM +, Peng Fan wrote:
> > Hi Mirela,
> >
> > Good to know that you are working suspend/resume support. Currently we
> > are also trying to support this on i.MX8, just wonder do you have any
> > open source available to support suspend to ram?
> >
> > > +
> > > +Suspend to RAM (in the following text 'suspend') for ARM in Xen
> > > +should be coordinated using ARM PSCI standard [1].
> > > +
> > > +Ideally, EL1/2 should suspend in the following order:
> > > +1) Unprivileged guests (DomUs) suspend
> > > +2) Privileged guest (Dom0) suspends
> > > +3) Xen suspends
> > > +
> > > +However, suspending unprivileged guests is not mandatory for
> > > +suspending
> > > +Dom0 and Xen. System suspend initiated by Dom0 (step 2) is
> > > +considered to be an ultimate decision to suspend the physical
> > > +machine. Suspending of Xen (step 3) is triggered whenever Dom0
> > > +completes suspend. Xen suspend leads to the full suspend of EL2.
> > > +
> > > +If an unprivileged guest is not suspended at the moment when Dom0
> > > +initiates its own suspend, the guest will be paused on Xen's
> > > +suspend and unpaused on Xen's resume. That way, a guest which
> > > +doesn't have power management support cannot prevent the physical
> > > +system from suspending when the decision to suspend is made by
> > > +privileged software
> > > (Dom0).
> > > +
> > > +Each guest in the system is responsible for suspending the devices it 
> > > owns.
> > > +If a guest does not suspend a device, the device will continue to
> > > +operate as it is configured at the moment when the system suspends.
> > > +If a device triggers an interrupt while the physical system is
> > > +suspended, the
> > > system will resume.
> > > +
> > > +It is recommended for an unprivileged guest to participate in power
> > > +management in the following scenario:
> > > +Assume unprivileged guest owns a device which will trigger
> > > +interrupt at some point. This interrupt will wake-up the system. If
> > > +such a behavior is not wanted, coordination between Dom0 and the
> > > +guest is required in order to inform the guest about the intended 
> > > physical
> system suspend.
> > > +Then, the guest will have a chance to suspend the device or respond
> > > +to the
> > > request in an abort fashion.
> > > +
> > > +Since this proposal is focused on implementing PSCI-based suspend
> > > +mechanisms in Xen, communication with or among the guests is not
> > > +covered by
> > > this document.
> > > +The order of suspending the guests is assumed to be guaranteed by
> > > +the software running in EL1.
> > > +
> > > +This document covers the following:
> > > +1) Mechanism for suspending/resuming a guest:
> > > + 1.1) Suspend is initiated by the guest
> > > + 1.2) Resume is initiated by a device interrupt
> > > +2) Mechanism for pausing/unpausing running guests when Dom0
> > > +suspends
> >
> > Will this take care of passthroughed devices for DomU?
> 

Thanks for your reply. Sorry for late reply

> Hi Peng,
> 
> The ZynqMP uses the EEMI Firmware interface to do power-management.
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.x
> ilinx.com%2Fsupport%2Fdocumentation%2Fuser_guides%2Fug1200-eemi-api.p
> df=02%7C01%7Cpeng.fan%40nxp.com%7C021307a245394e945cbf08d59
> 30ebb3c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C6365766138
> 46476140=xwyil1ar7VXXYPJb2yXxYPWJvR5mVEb6wokggdt0ZH4%3D
> served=0

Yes. I see. 

> 
> In our case, we've implemented an EEMI mediator in Xen that traps EEMI
> requests from domU's and makes sure that the guest owns the device it is 
> trying
> to operate on.
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> com%2FXilinx%2Fxen%2Fblob%2Fxilinx%2Fstable-4.9%2Fxen%2Farch%2Farm%
> 2Fplatforms%2Fxilinx-zynqmp-eemi.c=02%7C01%7Cpeng.fan%40nxp.com
> %7C021307a245394e945cbf08d5930ebb3c%7C686ea1d3bc2b4c6fa92cd99c5c3
> 01635%7C0%7C0%7C636576

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Edgar E. Iglesias]

On Mon, Mar 26, 2018 at 09:51:40AM +, Peng Fan wrote:
> Hi Mirela,
> 
> Good to know that you are working suspend/resume support. Currently we are 
> also trying
> to support this on i.MX8, just wonder do you have any open source available to
> support suspend to ram?
> 
> > +
> > +Suspend to RAM (in the following text 'suspend') for ARM in Xen should
> > +be coordinated using ARM PSCI standard [1].
> > +
> > +Ideally, EL1/2 should suspend in the following order:
> > +1) Unprivileged guests (DomUs) suspend
> > +2) Privileged guest (Dom0) suspends
> > +3) Xen suspends
> > +
> > +However, suspending unprivileged guests is not mandatory for suspending
> > +Dom0 and Xen. System suspend initiated by Dom0 (step 2) is considered
> > +to be an ultimate decision to suspend the physical machine. Suspending
> > +of Xen (step 3) is triggered whenever Dom0 completes suspend. Xen
> > +suspend leads to the full suspend of EL2.
> > +
> > +If an unprivileged guest is not suspended at the moment when Dom0
> > +initiates its own suspend, the guest will be paused on Xen's suspend
> > +and unpaused on Xen's resume. That way, a guest which doesn't have
> > +power management support cannot prevent the physical system from
> > +suspending when the decision to suspend is made by privileged software
> > (Dom0).
> > +
> > +Each guest in the system is responsible for suspending the devices it owns.
> > +If a guest does not suspend a device, the device will continue to
> > +operate as it is configured at the moment when the system suspends. If
> > +a device triggers an interrupt while the physical system is suspended, the
> > system will resume.
> > +
> > +It is recommended for an unprivileged guest to participate in power
> > +management in the following scenario:
> > +Assume unprivileged guest owns a device which will trigger interrupt at
> > +some point. This interrupt will wake-up the system. If such a behavior
> > +is not wanted, coordination between Dom0 and the guest is required in
> > +order to inform the guest about the intended physical system suspend.
> > +Then, the guest will have a chance to suspend the device or respond to the
> > request in an abort fashion.
> > +
> > +Since this proposal is focused on implementing PSCI-based suspend
> > +mechanisms in Xen, communication with or among the guests is not covered by
> > this document.
> > +The order of suspending the guests is assumed to be guaranteed by the
> > +software running in EL1.
> > +
> > +This document covers the following:
> > +1) Mechanism for suspending/resuming a guest:
> > +   1.1) Suspend is initiated by the guest
> > +   1.2) Resume is initiated by a device interrupt
> > +2) Mechanism for pausing/unpausing running guests when Dom0 suspends
> 
> Will this take care of passthroughed devices for DomU?

Hi Peng,

The ZynqMP uses the EEMI Firmware interface to do power-management.
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf

In our case, we've implemented an EEMI mediator in Xen that traps EEMI
requests from domU's and makes sure that the guest owns the device it
is trying to operate on.
https://github.com/Xilinx/xen/blob/xilinx/stable-4.9/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c

So domU will first issue the usual EEMI calls as it would in a non-virtualized
case to suspend all it's devices. Once that has happened, the guest will issue
PSCI calls to suspend the VM. So, Mirela please shim in if I missed something.

The EEMI mediator has been posted to the ML but is currently sitting in our
tree waiting for us to go through the upstreaming effort.

Cheers,
Edgar




> 
> Thanks,
> Peng.
> 
> > +3) Mechanism for suspending/resuming Xen when Dom0 completes suspend
> > +4) Resuming from any state on a wake-up event (device interrupt):
> > +   4.1) Resume DomU on wake-up event when Dom0 is still running
> > +   4.2) Resume DomU on wake-up event when Xen is suspended
> > +   4.3) Resume Dom0 on wake-up event
> > +
> > +Mechanisms enumerated above will allow different kind of policies and
> > +coordination among guests to be implemented in EL1. That is out of the
> > +scope of this document.
> > +
> > +-
> > +Suspending Guests
> > +-
> > +
> > +Suspend procedure for a guest consists of the following:
> > +1) Suspending devices
> > +2) Suspending non-boot CPUs (based on hotplug/PSCI)
> > +3) System suspend, performed by the boot CPU
> > +
> > +Each guest should suspend the devices it owns just like it would when
> > +running without Xen.
> > +
> > +Guests should suspend their non-boot vCPUs using the hotplug mechanism.
> > +Virtual CPUs should be put offline using the already implemented PSCI
> > +vCPU_OFF call (prefix 'v' is added to distinguish PSCI calls made by
> > +guests to Xen, which affect virtual machines; as opposed to PSCI calls
> > +made by Xen to the EL3, which can affect power state of the physical
> > machine).
> > +
> > +After suspending its non-boot vCPUs a guest should finalize 

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Peng Fan]

Hi Mirela,

Good to know that you are working suspend/resume support. Currently we are also 
trying
to support this on i.MX8, just wonder do you have any open source available to
support suspend to ram?

> +
> +Suspend to RAM (in the following text 'suspend') for ARM in Xen should
> +be coordinated using ARM PSCI standard [1].
> +
> +Ideally, EL1/2 should suspend in the following order:
> +1) Unprivileged guests (DomUs) suspend
> +2) Privileged guest (Dom0) suspends
> +3) Xen suspends
> +
> +However, suspending unprivileged guests is not mandatory for suspending
> +Dom0 and Xen. System suspend initiated by Dom0 (step 2) is considered
> +to be an ultimate decision to suspend the physical machine. Suspending
> +of Xen (step 3) is triggered whenever Dom0 completes suspend. Xen
> +suspend leads to the full suspend of EL2.
> +
> +If an unprivileged guest is not suspended at the moment when Dom0
> +initiates its own suspend, the guest will be paused on Xen's suspend
> +and unpaused on Xen's resume. That way, a guest which doesn't have
> +power management support cannot prevent the physical system from
> +suspending when the decision to suspend is made by privileged software
> (Dom0).
> +
> +Each guest in the system is responsible for suspending the devices it owns.
> +If a guest does not suspend a device, the device will continue to
> +operate as it is configured at the moment when the system suspends. If
> +a device triggers an interrupt while the physical system is suspended, the
> system will resume.
> +
> +It is recommended for an unprivileged guest to participate in power
> +management in the following scenario:
> +Assume unprivileged guest owns a device which will trigger interrupt at
> +some point. This interrupt will wake-up the system. If such a behavior
> +is not wanted, coordination between Dom0 and the guest is required in
> +order to inform the guest about the intended physical system suspend.
> +Then, the guest will have a chance to suspend the device or respond to the
> request in an abort fashion.
> +
> +Since this proposal is focused on implementing PSCI-based suspend
> +mechanisms in Xen, communication with or among the guests is not covered by
> this document.
> +The order of suspending the guests is assumed to be guaranteed by the
> +software running in EL1.
> +
> +This document covers the following:
> +1) Mechanism for suspending/resuming a guest:
> + 1.1) Suspend is initiated by the guest
> + 1.2) Resume is initiated by a device interrupt
> +2) Mechanism for pausing/unpausing running guests when Dom0 suspends

Will this take care of passthroughed devices for DomU?

Thanks,
Peng.

> +3) Mechanism for suspending/resuming Xen when Dom0 completes suspend
> +4) Resuming from any state on a wake-up event (device interrupt):
> + 4.1) Resume DomU on wake-up event when Dom0 is still running
> + 4.2) Resume DomU on wake-up event when Xen is suspended
> + 4.3) Resume Dom0 on wake-up event
> +
> +Mechanisms enumerated above will allow different kind of policies and
> +coordination among guests to be implemented in EL1. That is out of the
> +scope of this document.
> +
> +-
> +Suspending Guests
> +-
> +
> +Suspend procedure for a guest consists of the following:
> +1) Suspending devices
> +2) Suspending non-boot CPUs (based on hotplug/PSCI)
> +3) System suspend, performed by the boot CPU
> +
> +Each guest should suspend the devices it owns just like it would when
> +running without Xen.
> +
> +Guests should suspend their non-boot vCPUs using the hotplug mechanism.
> +Virtual CPUs should be put offline using the already implemented PSCI
> +vCPU_OFF call (prefix 'v' is added to distinguish PSCI calls made by
> +guests to Xen, which affect virtual machines; as opposed to PSCI calls
> +made by Xen to the EL3, which can affect power state of the physical
> machine).
> +
> +After suspending its non-boot vCPUs a guest should finalize the suspend
> +by making the vSYSTEM_SUSPEND PSCI call. The resume address is
> +specified by the guest via the vSYSTEM_SUSPEND entry_point_address
> +argument. The vSYSTEM_SUSPEND call is currently not implemented in Xen.
> +
> +It is expected that a guest leaves enabled all interrupts that should
> +wake it up. Other interrupts should be disabled by the guest prior to
> +calling vSYSTEM_SUSPEND.
> +
> +After an unprivileged guest suspends, Xen will not suspend. Xen would
> +suspend only after the Dom0 completes the system suspend.
> +
> +--
> +Suspending Xen
> +--
> +
> +Xen should start suspending itself upon receiving the vSYSTEM_SUSPEND
> +call from the last running guest (Dom0). At that moment all physical
> +CPUs are still online (taking offline a vCPU or suspending a VM does not 
> affect
> physical CPUs).
> +Xen shall now put offline the non-boot pCPUs by making the CPU_OFF PSCI
> +call to EL3. The CPU_OFF PSCI function is currently not implemented in Xen.
> +
> +After putting offline the 

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Julien Grall]

On 24/01/18 17:55, Mirela Simonovic wrote:

Hi Julien, Stefano,


Hi Mirela,



Thank you very much for the feedback!


On 01/11/2018 03:00 PM, Julien Grall wrote:

Hi Mirela,

Thank you for the sending the design document. The general design 
looks good to me. I have some comments below, but they are more 
related to the implementation of CPU on/off in Xen.


On 22/12/17 17:41, Mirela Simonovic wrote:

[...]


+---
+Resuming Guests
+---
+
+Resume of the privileged guest (Dom0) is always following the Xen 
resume.

+
+An unprivileged guest shall resume once a device it owns triggers a 
wake-up
+interrupt, regardless of whether Xen was suspended when the wake-up 
interrupt
+was triggered. If Xen was suspended, it is assumed that Dom0 will be 
running
+before the DomU guest starts to resume. The synchronization 
mechanism to

+enforce the assumed condition is TBD.


Given that all but the non-boot CPU will be offlined. Does the wake-up 
interrupt always need to target the non-boot CPU?


Wake-up interrupt needs to be targeted to the boot pCPU, and the resume 
sequence has to start from the boot pCPU.


I assume that wake-up interrupts could belong to a guest.
In that case, the wake-up interrupts will need to be moved to the boot 
pCPU on suspend.


[...]



For instance, you likely need to migrate interrupts that was assigned 
to the physical CPU (either guest one or Xen one). Though Xen ones 
might be less a concern because I think they are always assigned to 
CPU0 at the moment.


I would very appreciate more information on this. These kind of 
scenarios can be easily overlooked and I'm not that much experienced 
with pinning and its side effects.
Lets assume a vCPU is pinned to the non-boot CPU#1. When the guest 
enables an interrupt (interrupt is targeted to the vCPU), would Xen 
target physical interrupt to the GIC CPU interface of pCPU#1 or pCPU#0 
or all pCPUs?


In your example, the interrupts will target pCPU#1 only.





Furthermore, PPI handlers are not removed. Same for any memory 
allocated (you may loose reference to it because percpu area for that 
CPU will get freed). I believe get into trouble when the CPU is back 
online?


Yes, I needed to add few fixes into existing code to enable pCPU to come 
back online. I'll submit RFC soon.


Thank you!

[...]



I may have miss other bits, so I would highly recommend to go through 
the boot code and see what could go wrong.


[..]


+Resume Flow
+
+The resume entry point shall be implemented in
+* hyp_resume() in arch/arm/arm64/entry.S
+The very beginning of the resume procedure has to be implemented in 
assembly.

+It shall contain the following:
+* Enable the MMU so that the structure containing CPU context which 
was saved on

+suspend can be accessed
+* Restore CPU context (to match the values saved on suspend) and 
return into C

+* Set the system_state variable to SYS_STATE_resume
+* Restore GIC context
+* Resume timer
+* Enable interrupts
+* Enable non-boot CPUs by calling enable_nonboot_cpus()


You would have to be careful on re-enabling the non-CPU. 
start_secondary is implemented based on the assumption that it will 
only be called during Xen boot. Some of the code may be part of __init 
(see cpu_up_send_sgi) or should not be called as it is after boot (e.g 
check_local_cpu_errata).


Another I have in mind is the way VTCR_EL2 is set today (see 
setup_virt_paging). It is done at boot time, so if you online a CPU 
afterwards, VTCR_EL2 will not be set correctly.


Was there any reason to configure VTCR_EL2 after all CPUs become online?

I fixed this as follows: in start_xen(), the boot CPU calls 
setup_virt_paging() prior to enabling non-boot CPUs. setup_virt_paging() 
configures VTCR_EL2 only for the boot CPU.
Non-boot CPUs call setup_virt_paging_one() later, from 
start_secondary(). Also, only the boot CPU performs the calculation for 
how to configure VTCR_EL2, non-boot CPUs rely on the calculated value.
This would not be correct. Imagine a platform with heterogeneous 
processors (such as big.LITTLE), each processors may have different set 
of "features" (e.g max IPA size supported). You want Xen to use a common 
set of "features" that would work on all CPUs.


To give an example, your boot CPU may support maximum 48-bit IPA while 
all the other CPUs would support maximum 40-bit IPA. If Xen decides to 
use maximum 48-bit IPA, then page-tables would not work on other CPUs.


In order to take the decision, you need to wait all CPUs to come up and 
look at their ID registers. Once the decision is made, then you can 
configure correctly VTCR_EL2.


This is why setup_virt_paging() is called after all the CPUs have booted.

Obviously, this does not work for CPUs brought up afterwards (e.g resume 
case). For those CPUs we should call setup_virt_paging_one directly and 
check that the value chosen by Xen can be handled by the processor. If 
not, this CPU should be parked.


I think you can use 

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Julien Grall]

Hi Edgar,

On 25/01/18 14:15, Edgar E. Iglesias wrote:

On Wed, Jan 24, 2018 at 07:04:35PM +0100, Mirela Simonovic wrote:

Hi Oleksandr, Edgar,


Thanks, you're right.


On 01/23/2018 12:58 PM, Edgar E. Iglesias wrote:

On Tue, Jan 23, 2018 at 01:52:50PM +0200, Oleksandr Tyshchenko wrote:

Hi Mirela,

Just some remarks regarding the scope of work:

+In addition, the following have to be implemented:
+* Suspend/resume vCPU (triggered by vSYSTEM_SUSPEND call)
+* Suspend/resume Xen (triggered by vSYSTEM_SUSPEND called by Dom0), including:
+   * Disable wathdog on suspend, enable it on resume
+   * Pause domains on suspend, unpause them on resume
+   * Disable non-boot pCPUs on suspend, enable them on resume
+   * Save/restore of GIC configuration
+   * Suspend/resume timer
+   * Save/restore of EL2 context
+   * Implement resume entry point in Xen, including MMU configuration

I think that saving/restoring IOMMU registers/context should be
implemented as well.

Yes, good point.
Mirela, I think that in the ZU+ case the IOMMU actually gets powered down
with the FPD.


Yes, it is in FPD.


Having said that it may still be useful from a patch review perspective
to incrementally add things. Perhaps the IOMMU suspending support could
come in follow-up patch series if others agree.


+1 :). I suspect the suspend/resume patch set will be quite big. So 
anything that can help the review (e.g splitting patch series, moving 
out some parts of the initial work...) would be greatly appreciated.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Edgar E. Iglesias]

On Wed, Jan 24, 2018 at 07:04:35PM +0100, Mirela Simonovic wrote:
> Hi Oleksandr, Edgar,
> 
> 
> Thanks, you're right.
> 
> 
> On 01/23/2018 12:58 PM, Edgar E. Iglesias wrote:
> >On Tue, Jan 23, 2018 at 01:52:50PM +0200, Oleksandr Tyshchenko wrote:
> >>Hi Mirela,
> >>
> >>Just some remarks regarding the scope of work:
> >>
> >>+In addition, the following have to be implemented:
> >>+* Suspend/resume vCPU (triggered by vSYSTEM_SUSPEND call)
> >>+* Suspend/resume Xen (triggered by vSYSTEM_SUSPEND called by Dom0), 
> >>including:
> >>+   * Disable wathdog on suspend, enable it on resume
> >>+   * Pause domains on suspend, unpause them on resume
> >>+   * Disable non-boot pCPUs on suspend, enable them on resume
> >>+   * Save/restore of GIC configuration
> >>+   * Suspend/resume timer
> >>+   * Save/restore of EL2 context
> >>+   * Implement resume entry point in Xen, including MMU configuration
> >>
> >>I think that saving/restoring IOMMU registers/context should be
> >>implemented as well.
> >Yes, good point.
> >Mirela, I think that in the ZU+ case the IOMMU actually gets powered down
> >with the FPD.
> 
> Yes, it is in FPD.

Having said that it may still be useful from a patch review perspective
to incrementally add things. Perhaps the IOMMU suspending support could
come in follow-up patch series if others agree.

Best regards,
Edgar



> >
> >
> >>In other words, each involved platform device driver in Xen on ARM
> >>(IOMMU-XX, UART-XX, etc) should have suspend/resume callbacks
> >>implemented.
> 
> Yes, callback should be platform specific but not each platform has to have
> all callbacks implemented. E.g. on ZU+ UART is in differrent power domain
> compared to APU/Xen. Xen can suspend and its power domain can go down even
> if UART is not suspended. However, suspending UART even in this case may be
> beneficial from power perspective. We should definitely provide the option
> to implement the callback.
> 
> AFAIU, the following devices has to be suspended:
> 1. timer
> 2. IOMMU
> 3. UART
> 4. GIC
> 
> Please let me know if I missed something. I'll update this in next design
> spec version. Thank you very much for good feedback!
> 
> Cheers,
> Mirela
> >Yes agreed.
> >
> >Best regards,
> >Edgar
> >
> >
> >>-- 
> >>Regards,
> >>
> >>Oleksandr Tyshchenko
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Mirela Simonovic]

Hi Oleksandr, Edgar,


Thanks, you're right.


On 01/23/2018 12:58 PM, Edgar E. Iglesias wrote:

On Tue, Jan 23, 2018 at 01:52:50PM +0200, Oleksandr Tyshchenko wrote:

Hi Mirela,

Just some remarks regarding the scope of work:

+In addition, the following have to be implemented:
+* Suspend/resume vCPU (triggered by vSYSTEM_SUSPEND call)
+* Suspend/resume Xen (triggered by vSYSTEM_SUSPEND called by Dom0), including:
+   * Disable wathdog on suspend, enable it on resume
+   * Pause domains on suspend, unpause them on resume
+   * Disable non-boot pCPUs on suspend, enable them on resume
+   * Save/restore of GIC configuration
+   * Suspend/resume timer
+   * Save/restore of EL2 context
+   * Implement resume entry point in Xen, including MMU configuration

I think that saving/restoring IOMMU registers/context should be
implemented as well.

Yes, good point.
Mirela, I think that in the ZU+ case the IOMMU actually gets powered down
with the FPD.


Yes, it is in FPD.




In other words, each involved platform device driver in Xen on ARM
(IOMMU-XX, UART-XX, etc) should have suspend/resume callbacks
implemented.


Yes, callback should be platform specific but not each platform has to 
have all callbacks implemented. E.g. on ZU+ UART is in differrent power 
domain compared to APU/Xen. Xen can suspend and its power domain can go 
down even if UART is not suspended. However, suspending UART even in 
this case may be beneficial from power perspective. We should definitely 
provide the option to implement the callback.


AFAIU, the following devices has to be suspended:
1. timer
2. IOMMU
3. UART
4. GIC

Please let me know if I missed something. I'll update this in next 
design spec version. Thank you very much for good feedback!


Cheers,
Mirela

Yes agreed.

Best regards,
Edgar



--
Regards,

Oleksandr Tyshchenko



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Mirela Simonovic]

Hi Julien, Stefano,


Thank you very much for the feedback!


On 01/11/2018 03:00 PM, Julien Grall wrote:

Hi Mirela,

Thank you for the sending the design document. The general design 
looks good to me. I have some comments below, but they are more 
related to the implementation of CPU on/off in Xen.


On 22/12/17 17:41, Mirela Simonovic wrote:

[...]


+---
+Resuming Guests
+---
+
+Resume of the privileged guest (Dom0) is always following the Xen 
resume.

+
+An unprivileged guest shall resume once a device it owns triggers a 
wake-up
+interrupt, regardless of whether Xen was suspended when the wake-up 
interrupt
+was triggered. If Xen was suspended, it is assumed that Dom0 will be 
running
+before the DomU guest starts to resume. The synchronization 
mechanism to

+enforce the assumed condition is TBD.


Given that all but the non-boot CPU will be offlined. Does the wake-up 
interrupt always need to target the non-boot CPU?


Wake-up interrupt needs to be targeted to the boot pCPU, and the resume 
sequence has to start from the boot pCPU.





+
+If the ARM's GIC was powered down after the ARM subsystem suspended, 
it is
+assumed that Xen needs to restore the GIC interface for a VM prior 
to handing
+over control to the guest. However, the guest should restore its own 
context
+upon entering the resume point, just like it would when running 
without Xen.

+
+===
+Implementation
+===


[...]


+CPU_OFF (physical CPUs)
+---
+The CPU_OFF function shall be implemented in
+* call_psci_cpu_off() in arch/arm/psci.c
+
+The implementation shall consist just of making the SMC call to EL3.
+
+This function needs to be called when Xen generic code disables a 
non-boot CPU.
+When a CPU is disabled it will loop forever in while loop 
(stop_cpu() function

+which is already implemented in xen/arch/arm/smpboot.c). Call to
+call_psci_cpu_off() shall be made before the CPU enters infinite loop.


While the code is present, we never offline physical CPU at the moment 
except when shutting down the place. So I am not fully convinced that 
stop_cpu() is properly implemented.


stop_cpu() is called in shutdown scenario, but not from the same place 
as it would be called in suspend scenario.
In suspend scenario, the boot CPU is performing suspend procedure (to be 
implemented) and as one of the steps it will disable non-boot CPUs by 
calling the existing disable_nonboot_cpus() function (x86 suspend flow 
does the same).
disable_nonboot_cpus() will lead to triggering each non-boot CPU to 
execute stop_cpu() for itself. In this respect, I believe stop_cpu() 
should be only extended to call PSCI CPU_OFF in order to trigger 
powering down of the calling CPU.
Consequently, in the shutdown scenario non-boot CPUs will also be 
powered down, but this is beneficial and comes for free with the suspend 
support.


However, you're right - more needs to be done elsewhere.



For instance, you likely need to migrate interrupts that was assigned 
to the physical CPU (either guest one or Xen one). Though Xen ones 
might be less a concern because I think they are always assigned to 
CPU0 at the moment.


I would very appreciate more information on this. These kind of 
scenarios can be easily overlooked and I'm not that much experienced 
with pinning and its side effects.
Lets assume a vCPU is pinned to the non-boot CPU#1. When the guest 
enables an interrupt (interrupt is targeted to the vCPU), would Xen 
target physical interrupt to the GIC CPU interface of pCPU#1 or pCPU#0 
or all pCPUs?




Furthermore, PPI handlers are not removed. Same for any memory 
allocated (you may loose reference to it because percpu area for that 
CPU will get freed). I believe get into trouble when the CPU is back 
online?


Yes, I needed to add few fixes into existing code to enable pCPU to come 
back online. I'll submit RFC soon.


Thanks,
Mirela



I may have miss other bits, so I would highly recommend to go through 
the boot code and see what could go wrong.


[..]


+Resume Flow
+
+The resume entry point shall be implemented in
+* hyp_resume() in arch/arm/arm64/entry.S
+The very beginning of the resume procedure has to be implemented in 
assembly.

+It shall contain the following:
+* Enable the MMU so that the structure containing CPU context which 
was saved on

+suspend can be accessed
+* Restore CPU context (to match the values saved on suspend) and 
return into C

+* Set the system_state variable to SYS_STATE_resume
+* Restore GIC context
+* Resume timer
+* Enable interrupts
+* Enable non-boot CPUs by calling enable_nonboot_cpus()


You would have to be careful on re-enabling the non-CPU. 
start_secondary is implemented based on the assumption that it will 
only be called during Xen boot. Some of the code may be part of __init 
(see cpu_up_send_sgi) or should not be called as it is after boot (e.g 
check_local_cpu_errata).


Another I have in mind is the way VTCR_EL2 is 

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Edgar E. Iglesias]

On Tue, Jan 23, 2018 at 01:52:50PM +0200, Oleksandr Tyshchenko wrote:
> Hi Mirela,
> 
> Just some remarks regarding the scope of work:
> 
> +In addition, the following have to be implemented:
> +* Suspend/resume vCPU (triggered by vSYSTEM_SUSPEND call)
> +* Suspend/resume Xen (triggered by vSYSTEM_SUSPEND called by Dom0), 
> including:
> +   * Disable wathdog on suspend, enable it on resume
> +   * Pause domains on suspend, unpause them on resume
> +   * Disable non-boot pCPUs on suspend, enable them on resume
> +   * Save/restore of GIC configuration
> +   * Suspend/resume timer
> +   * Save/restore of EL2 context
> +   * Implement resume entry point in Xen, including MMU configuration
> 
> I think that saving/restoring IOMMU registers/context should be
> implemented as well.

Yes, good point.
Mirela, I think that in the ZU+ case the IOMMU actually gets powered down
with the FPD.


> In other words, each involved platform device driver in Xen on ARM
> (IOMMU-XX, UART-XX, etc) should have suspend/resume callbacks
> implemented.

Yes agreed.

Best regards,
Edgar


> 
> -- 
> Regards,
> 
> Oleksandr Tyshchenko

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Oleksandr Tyshchenko]

Hi Mirela,

Just some remarks regarding the scope of work:

+In addition, the following have to be implemented:
+* Suspend/resume vCPU (triggered by vSYSTEM_SUSPEND call)
+* Suspend/resume Xen (triggered by vSYSTEM_SUSPEND called by Dom0), including:
+   * Disable wathdog on suspend, enable it on resume
+   * Pause domains on suspend, unpause them on resume
+   * Disable non-boot pCPUs on suspend, enable them on resume
+   * Save/restore of GIC configuration
+   * Suspend/resume timer
+   * Save/restore of EL2 context
+   * Implement resume entry point in Xen, including MMU configuration

I think that saving/restoring IOMMU registers/context should be
implemented as well.
In other words, each involved platform device driver in Xen on ARM
(IOMMU-XX, UART-XX, etc) should have suspend/resume callbacks
implemented.

-- 
Regards,

Oleksandr Tyshchenko

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Julien Grall]

Hi Mirela,

Thank you for the sending the design document. The general design looks 
good to me. I have some comments below, but they are more related to the 
implementation of CPU on/off in Xen.


On 22/12/17 17:41, Mirela Simonovic wrote:

[...]


+---
+Resuming Guests
+---
+
+Resume of the privileged guest (Dom0) is always following the Xen resume.
+
+An unprivileged guest shall resume once a device it owns triggers a wake-up
+interrupt, regardless of whether Xen was suspended when the wake-up interrupt
+was triggered. If Xen was suspended, it is assumed that Dom0 will be running
+before the DomU guest starts to resume. The synchronization mechanism to
+enforce the assumed condition is TBD.


Given that all but the non-boot CPU will be offlined. Does the wake-up 
interrupt always need to target the non-boot CPU?



+
+If the ARM's GIC was powered down after the ARM subsystem suspended, it is
+assumed that Xen needs to restore the GIC interface for a VM prior to handing
+over control to the guest. However, the guest should restore its own context
+upon entering the resume point, just like it would when running without Xen.
+
+===
+Implementation
+===


[...]


+CPU_OFF (physical CPUs)
+---
+The CPU_OFF function shall be implemented in
+* call_psci_cpu_off() in arch/arm/psci.c
+
+The implementation shall consist just of making the SMC call to EL3.
+
+This function needs to be called when Xen generic code disables a non-boot CPU.
+When a CPU is disabled it will loop forever in while loop (stop_cpu() function
+which is already implemented in xen/arch/arm/smpboot.c). Call to
+call_psci_cpu_off() shall be made before the CPU enters infinite loop.


While the code is present, we never offline physical CPU at the moment 
except when shutting down the place. So I am not fully convinced that 
stop_cpu() is properly implemented.


For instance, you likely need to migrate interrupts that was assigned to 
the physical CPU (either guest one or Xen one). Though Xen ones might be 
less a concern because I think they are always assigned to CPU0 at the 
moment.


Furthermore, PPI handlers are not removed. Same for any memory allocated 
(you may loose reference to it because percpu area for that CPU will get 
freed). I believe get into trouble when the CPU is back online?


I may have miss other bits, so I would highly recommend to go through 
the boot code and see what could go wrong.


[..]


+Resume Flow
+
+The resume entry point shall be implemented in
+* hyp_resume() in arch/arm/arm64/entry.S
+The very beginning of the resume procedure has to be implemented in assembly.
+It shall contain the following:
+* Enable the MMU so that the structure containing CPU context which was saved 
on
+suspend can be accessed
+* Restore CPU context (to match the values saved on suspend) and return into C
+* Set the system_state variable to SYS_STATE_resume
+* Restore GIC context
+* Resume timer
+* Enable interrupts
+* Enable non-boot CPUs by calling enable_nonboot_cpus()


You would have to be careful on re-enabling the non-CPU. start_secondary 
is implemented based on the assumption that it will only be called 
during Xen boot. Some of the code may be part of __init (see 
cpu_up_send_sgi) or should not be called as it is after boot (e.g 
check_local_cpu_errata).


Another I have in mind is the way VTCR_EL2 is set today (see 
setup_virt_paging). It is done at boot time, so if you online a CPU 
afterwards, VTCR_EL2 will not be set correctly.


I probably have missed other bits. I am happy to provide more insights here.

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Stefano Stabellini]

On Fri, 22 Dec 2017, Mirela Simonovic wrote:
> This document contains our design specification for "suspend to RAM"
> support for ARM in Xen. It covers the basic suspend to RAM mechanism
> based on ARM PSCI standard, that would allow individual guests and
> Xen itself to suspend/resume.
> 
> We would appreciate your feedback.
> 
> Signed-off-by: Mirela Simonovic 

Sounds good to me

Acked-by: Stefano Stabellini 


> ---
> v2:
> -Improved specification according to comments
> -Added more implementation details
> -Incremented revision number to 1.1
> ---
>  docs/misc/arm/suspend-to-ram.txt | 266 
> +++
>  1 file changed, 266 insertions(+)
>  create mode 100644 docs/misc/arm/suspend-to-ram.txt
> 
> diff --git a/docs/misc/arm/suspend-to-ram.txt 
> b/docs/misc/arm/suspend-to-ram.txt
> new file mode 100644
> index 00..6e8f10d1ce
> --- /dev/null
> +++ b/docs/misc/arm/suspend-to-ram.txt
> @@ -0,0 +1,266 @@
> +% Suspend to RAM Support in Xen for ARM
> +% Revision 1.1
> +
> +
> +Overview
> +
> +
> +Suspend to RAM (in the following text 'suspend') for ARM in Xen should be
> +coordinated using ARM PSCI standard [1].
> +
> +Ideally, EL1/2 should suspend in the following order:
> +1) Unprivileged guests (DomUs) suspend
> +2) Privileged guest (Dom0) suspends
> +3) Xen suspends
> +
> +However, suspending unprivileged guests is not mandatory for suspending
> +Dom0 and Xen. System suspend initiated by Dom0 (step 2) is considered to be 
> an
> +ultimate decision to suspend the physical machine. Suspending of Xen (step 3)
> +is triggered whenever Dom0 completes suspend. Xen suspend leads to the full
> +suspend of EL2.
> +
> +If an unprivileged guest is not suspended at the moment when Dom0 initiates
> +its own suspend, the guest will be paused on Xen's suspend and unpaused on
> +Xen's resume. That way, a guest which doesn't have power management support
> +cannot prevent the physical system from suspending when the decision to 
> suspend
> +is made by privileged software (Dom0).
> +
> +Each guest in the system is responsible for suspending the devices it owns.
> +If a guest does not suspend a device, the device will continue to operate as
> +it is configured at the moment when the system suspends. If a device triggers
> +an interrupt while the physical system is suspended, the system will resume.
> +
> +It is recommended for an unprivileged guest to participate in power 
> management
> +in the following scenario:
> +Assume unprivileged guest owns a device which will trigger interrupt at some
> +point. This interrupt will wake-up the system. If such a behavior is not 
> wanted,
> +coordination between Dom0 and the guest is required in order to inform the 
> guest
> +about the intended physical system suspend. Then, the guest will have a 
> chance
> +to suspend the device or respond to the request in an abort fashion.
> +
> +Since this proposal is focused on implementing PSCI-based suspend mechanisms 
> in
> +Xen, communication with or among the guests is not covered by this document.
> +The order of suspending the guests is assumed to be guaranteed by the 
> software
> +running in EL1.
> +
> +This document covers the following:
> +1) Mechanism for suspending/resuming a guest:
> + 1.1) Suspend is initiated by the guest
> + 1.2) Resume is initiated by a device interrupt
> +2) Mechanism for pausing/unpausing running guests when Dom0 suspends
> +3) Mechanism for suspending/resuming Xen when Dom0 completes suspend
> +4) Resuming from any state on a wake-up event (device interrupt):
> + 4.1) Resume DomU on wake-up event when Dom0 is still running
> + 4.2) Resume DomU on wake-up event when Xen is suspended
> + 4.3) Resume Dom0 on wake-up event
> +
> +Mechanisms enumerated above will allow different kind of policies and
> +coordination among guests to be implemented in EL1. That is out of the scope 
> of
> +this document.
> +
> +-
> +Suspending Guests
> +-
> +
> +Suspend procedure for a guest consists of the following:
> +1) Suspending devices
> +2) Suspending non-boot CPUs (based on hotplug/PSCI)
> +3) System suspend, performed by the boot CPU
> +
> +Each guest should suspend the devices it owns just like it would when running
> +without Xen.
> +
> +Guests should suspend their non-boot vCPUs using the hotplug mechanism.
> +Virtual CPUs should be put offline using the already implemented PSCI 
> vCPU_OFF
> +call (prefix 'v' is added to distinguish PSCI calls made by guests to Xen, 
> which
> +affect virtual machines; as opposed to PSCI calls made by Xen to the EL3, 
> which
> +can affect power state of the physical machine).
> +
> +After suspending its non-boot vCPUs a guest should finalize the suspend by
> +making the vSYSTEM_SUSPEND PSCI call. The resume address is specified by the
> +guest via the vSYSTEM_SUSPEND entry_point_address argument. The 
> vSYSTEM_SUSPEND
>