On Fri, Dec 13, 2024 at 6:17 PM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
>
> On Fri, 2024-12-13 at 18:05 +0100, Thomas Gleixner wrote:
> >
> > > Agreed. The hacky proof of concept I posted earlier invoking
> > > machine_kexec() instead of suspend_ops->enter() works fine. I'll look
> > > at cleaning it up and making it not invoke all the ACPI hooks for
> > > *actual* suspend to RAM, etc.
> >
> > Something like the below? It survived an hour of loop testing.
>
> If I read that correctly, it's still invoking the standard platform
> (e.g. ACPI) hooks for suspend-to-RAM, when it probably shouldn't?
>
> I suspect it wants its *own* set of platform_suspend_ops, which are
> mostly empty apart from the ->enter() ?
>
> I started looking at that, but now my eyes are currently bleeding after
> seeing the existing platform_suspend_ops vs. platform_s2idle_ops
> structures, which are kind of similar but not the same. And the set of
> helper functions which invoke one or the other, from the barely
> tolerable platform_resume_end()...
>
> static void platform_resume_end(suspend_state_t state)
> {
> if (state == PM_SUSPEND_TO_IDLE && s2idle_ops && s2idle_ops->end)
> s2idle_ops->end();
> else if (suspend_ops && suspend_ops->end)
> suspend_ops->end();
> }
>
> ... to the extra-special platform_resume_noirq() which is similar
> except that it needs three *different* names (_resume_noirq vs.
> restore_early vs. wake):
>
> static void platform_resume_noirq(suspend_state_t state)
> {
> if (state == PM_SUSPEND_TO_IDLE) {
> if (s2idle_ops && s2idle_ops->restore_early)
> s2idle_ops->restore_early();
> } else if (suspend_ops->wake) {
> suspend_ops->wake();
> }
> }
>
>
> I wonder if we end up wanting a *third* set there, for the kjump_ops?
No, no.
The "vision" behind kexec jump was to use it for implementing
hibernation, but that never happened.
It doesn't actually need any platform ops at all because everything it
does is to jump from one kernel to another, both residing in memory at
this point. No firmware is involved.
> Except can we unify the structure definitions and then just *use* the
> appropriate one of the three, which is either passed down or selected
> using the 'state'?
That can be done I suppose, but it won't help much in the kexec jump case.
