On 21.03.2025 10:49, Mykola Kvach wrote: > Hi, > > On Thu, Mar 13, 2025 at 5:37 PM Jan Beulich <jbeul...@suse.com> wrote: >> >> On 05.03.2025 10:11, Mykola Kvach wrote: >>> --- 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 >>> + depends on ARM_64 >>> + help >>> + This option enables the system suspend support. This is the >>> + mechanism that allows the system to be suspended to RAM and >>> + later resumed. >>> + >>> + If unsure, say Y. >> >> I wonder if something like this makes sense to place in an arch-specific > > Maybe it makes sense, but only if we are not planning to cover > suspend/resume related code for x86 as well. > >> Kconfig. It's also not becoming clear here why only Arm64 would permit it. > > If I understand your comment correctly, you’re suggesting that we > could use this for x86 as well.
Or PPC / RISC-V once they progress enough. > However, in that case, we would need > to make a lot of changes in other places that are not related to this > patch series, which is specifically focused on adding suspend/resume > support for Arm64. I believe that is outside the scope of this patch > series. Considering that - give or take bugs - S3 is working on x86, I'm not sure what lots of changes you're thinking of. In fact ... > However, this config was requested in one of the previous > patch series. The primary reason for adding this config was to reduce > the binary size for platforms where it isn’t used. I also think it can > be useful for debugging purposes, such as for identifying regressions. ... that's what I'd see as a (future) option on x86 as well. > As for Arm32, it’s not supported at the moment, but I hope support > will be added in the future. Which is another data point towards this wanting to move to common code, with a per-arch-selected HAVE_* as dependency. To cover that it's always-on for x86, an ..._ALWAYS_ON setting may want introducing as well (or some shorthand approach to limit [future] churn). Jan
