On 21.03.25 11:48, Mykola Kvach wrote:
Hi,
On Wed, Mar 12, 2025 at 12:29 AM Julien Grall <jul...@xen.org> wrote:
Hi,
On 05/03/2025 09:11, Mykola Kvach wrote:
From: Mykola Kvach <mykola_kv...@epam.com>
This option enables the system suspend support. This is the
mechanism that allows the system to be suspended to RAM and
later resumed.
Signed-off-by: Mykyta Poturai <mykyta_potu...@epam.com>
Signed-off-by: Mykola Kvach <mykola_kv...@epam.com>
---
xen/arch/arm/Kconfig | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index a26d3e1182..5834af16ab 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -475,6 +475,17 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
config ARM32_HARDEN_BRANCH_PREDICTOR
def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
+config SYSTEM_SUSPEND
+ bool "System suspend support"
+ default y
The default should likely be no until everything is working.
got it!
+ depends on ARM_64
I think this also needs to depends on !LLC_COLORING (unless you
confirmed cache coloring is working) and UNSUPPORTED.
Sure! I'll add the dependency.
+ help
+ This option enables the system suspend support. This is the
+ mechanism that allows the system to be suspended to RAM and
+ later resumed.
You seem to also tie guest suspend/resunme to this option. Is it intended?
From the guest's perspective, it is a system suspend. However, it looks like
the
description should be enhanced. Thank you for pointing that out.
s2r = "suspend to ram"
You definitely need consider and clarify ARM64 Guest System s2r and
XEN system s2r. First can be supported without second, while the XEN system s2r
depends on Guests System s2r support and required guests to be properly
suspended
before allowing XEN to enter system s2r.
You can't call freeze_domains() and blindly pause some domain, because if it's
not
suspend and has passed through HW which is in the middle of transaction ->
DEADBEEF.
--
Best regards,
-grygorii
