[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH 05/18] xen/arm: Trigger Xen suspend when Dom0 completes suspend
On 11/15/18 7:17 PM, Mirela Simonovic wrote:
Hi Julien,
On Thu, Nov 15, 2018 at 7:23 PM Julien Grall <julien.grall@xxxxxxx> wrote:
Hi Mirela,
On 11/12/18 11:30 AM, Mirela Simonovic wrote:
When Dom0 finalizes its suspend procedure the suspend of Xen is
triggered by calling system_suspend(). Dom0 finalizes the suspend from
its boot core (VCPU#0), which could be mapped to any physical CPU,
i.e. the system_suspend() function could be executed by any physical
CPU. Since Xen suspend procedure has to be run by the boot CPU
(non-boot CPUs will be disabled at some point in suspend procedure),
system_suspend() execution has to continue on CPU#0.
When the system_suspend() returns 0, it means that the system was
suspended and it is coming out of the resume procedure. Regardless
of the system_suspend() return value, after this function returns
Xen is fully functional, and its state, including all devices and data
structures, matches the state prior to calling system_suspend().
The status is returned by system_suspend() for debugging/logging
purposes and function prototype compatibility.
Signed-off-by: Mirela Simonovic <mirela.simonovic@xxxxxxxxxx>
Signed-off-by: Saeed Nowshadi <saeed.nowshadi@xxxxxxxxxx>
---
xen/arch/arm/suspend.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
index f2338e41db..21b45f8248 100644
--- a/xen/arch/arm/suspend.c
+++ b/xen/arch/arm/suspend.c
@@ -112,11 +112,20 @@ static void vcpu_suspend(register_t epoint, register_t
cid)
_arch_set_info_guest(v, &ctxt);
}
+/* Xen suspend. Note: data is not used (suspend is the suspend to RAM) */
+static long system_suspend(void *data)
+{
+ BUG_ON(system_state != SYS_STATE_active);
+
+ return -ENOSYS;
+}
+
int32_t domain_suspend(register_t epoint, register_t cid)
{
struct vcpu *v;
struct domain *d = current->domain;
bool is_thumb = epoint & 1;
+ int status;
dprintk(XENLOG_DEBUG,
"Dom%d suspend: epoint=0x%"PRIregister", cid=0x%"PRIregister"\n",
@@ -156,6 +165,31 @@ int32_t domain_suspend(register_t epoint, register_t cid)
*/
vcpu_block_unless_event_pending(current);
+ /* If this was dom0 the whole system should suspend: trigger Xen suspend */
+ if ( is_hardware_domain(d) )
+ {
+ /*
+ * system_suspend should be called when Dom0 finalizes the suspend
+ * procedure from its boot core (VCPU#0). However, Dom0's VCPU#0 could
+ * be mapped to any PCPU (this function could be executed by any PCPU).
+ * The suspend procedure has to be finalized by the PCPU#0 (non-boot
+ * PCPUs will be disabled during the suspend).
+ */
+ status = continue_hypercall_on_cpu(0, system_suspend, NULL);
+ /*
+ * If an error happened, there is nothing that needs to be done here
+ * because the system_suspend always returns in fully functional state
+ * no matter what the outcome of suspend procedure is. If the system
+ * suspended successfully the function will return 0 after the resume.
+ * Otherwise, if an error is returned it means Xen did not suspended,
+ * but it is still in the same state as if the system_suspend was never
+ * called. We dump a debug message in case of an error for debugging/
+ * logging purpose.
+ */
+ if ( status )
+ dprintk(XENLOG_ERR, "Failed to suspend, errno=%d\n", status);
+ }
After discussing we Stefano today, I have one more question regarding
Dom0 suspend.
From my understanding, the host may resume because of an event
targeting a guest. This means that Dom0 would still be blocked. As Dom0
would contain PV backend, how do you expect this to work?
Is there any potential dependency between frontend and backend? Or would
Dom0 be resume when the PV frontend probe the backend?
We have assumed that Dom0 has to resume whenever Xen resume. So if the
wake-up interrupt was targeted to DomU, the Dom0 would resume
regarless. Vice versa does not hold.
This is done in patch "[PATCH 17/18] xen/arm: Resume Dom0 after Xen
resumes" - the Dom0 is simply unblocked at the end of Xen's resume.
How about the disaggregated case where backend may live in a different
guest. How is this going to happen?
I have heard Stefano suggesting to resume all the domains but that seem
to be a massive hammer to solve it.
I am wondering whether we can rely on the frontend sending an event (i.e
event channel) in part of resuming the PV protocols.
Did you test it the PV protocols in the suspend/resume? I know that
Linux does not have everything for suspend/resume Xen Arm today. There
are some patches inflight (see [1]).
[1]
https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg00823.html
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
