Re: [PATCH 06/16] xen/arm: Introduce system suspend config option

[Jan Beulich <jbeulich@xxxxxxxx>]

On 21.03.2025 10:49, Mykola Kvach wrote:
> Hi,
> 
> On Thu, Mar 13, 2025 at 5:37 PM Jan Beulich <jbeulich@xxxxxxxx> 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