[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YzQui+rOGrM6otzp@zn.tnic>
Date: Wed, 28 Sep 2022 13:22:51 +0200
From: Borislav Petkov <bp@...en8.de>
To: Juergen Gross <jgross@...e.com>
Cc: xen-devel@...ts.xenproject.org, x86@...nel.org,
linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH v3 08/10] x86/mtrr: let cache_aps_delayed_init replace
mtrr_aps_delayed_init
On Wed, Sep 28, 2022 at 01:14:11PM +0200, Juergen Gross wrote:
> No, we don't.
>
> Using basically your patch, but with
>
> + mtrr_online = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
> + "x86/mtrr:online",
> + mtrr_ap_init, NULL);
>
> moved to the end of mtrr_aps_init(), and:
>
> +void mtrr_aps_thaw(void)
> +{
> + cpuhp_remove_state_nocalls(mtrr_online);
> +}
Yes, so you said. I'm not sure I like this toggling of notifier
registration like that.
Optimally, I'd like to be able to query the suspend code whether it is
in the process of resuming.
This here:
static int resume_target_kernel(bool platform_mode)
{
...
Enable_irqs:
system_state = SYSTEM_RUNNING;
local_irq_enable();
Enable_cpus:
pm_sleep_enable_secondary_cpus();
but being able to do:
pm_sleep_enable_secondary_cpus();
system_state = SYSTEM_RUNNING | SYSTEM_RUNNING_APS_UP;
which can't work, obviously. But something like that.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists