linux-kernel - Re: [RFC][PATCH] x86, CPU: Restore MSR_IA32_ENERGY_PERF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150717083953.GA27348@nazgul.tnic>
Date:	Fri, 17 Jul 2015 10:39:53 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Laura Abbott <labbott@...oraproject.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Andy Lutomirski <luto@...capital.net>
Subject: Re: [RFC][PATCH] x86, CPU: Restore MSR_IA32_ENERGY_PERF_BIAS after
 resume

On Thu, Jul 16, 2015 at 03:09:21PM -0700, Laura Abbott wrote:
> MSR_IA32_ENERGY_PERF_BIAS is lost after suspend/resume:
> 
> x86_energy_perf_policy -r before
> 
> cpu0: 0x0000000000000006
> cpu1: 0x0000000000000006
> cpu2: 0x0000000000000006
> cpu3: 0x0000000000000006
> cpu4: 0x0000000000000006
> cpu5: 0x0000000000000006
> cpu6: 0x0000000000000006
> cpu7: 0x0000000000000006
> 
> after
> 
> cpu0: 0x0000000000000000

Yap, I see it here too on an IVB laptop when doing s2r.

> cpu1: 0x0000000000000006
> cpu2: 0x0000000000000006
> cpu3: 0x0000000000000006
> cpu4: 0x0000000000000006
> cpu5: 0x0000000000000006
> cpu6: 0x0000000000000006
> cpu7: 0x0000000000000006
> 
> This register is set via init_intel at bootup. During resume, the
> secondary CPUs are brought online again and init_intel is callled which
> re-initializes the register. The boot cpu however never reinitializes
> the register. Add a syscore callback to reinitialize the register for
> the boot CPU.
> 
> Signed-off-by: Laura Abbott <labbott@...oraproject.org>
> ---
> RFC because I'm not that familiar with x86 suspend/resume inner workings.
> ---
>  arch/x86/kernel/cpu/common.c | 18 ++++++++++++++++++
>  arch/x86/kernel/cpu/cpu.h    |  1 +
>  arch/x86/kernel/cpu/intel.c  | 36 +++++++++++++++++++++---------------
>  3 files changed, 40 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 922c5e0..dc9f1e5 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -13,6 +13,7 @@
>  #include <linux/kgdb.h>
>  #include <linux/smp.h>
>  #include <linux/io.h>
> +#include <linux/syscore_ops.h>
>  
>  #include <asm/stackprotector.h>
>  #include <asm/perf_event.h>
> @@ -1488,3 +1489,20 @@ inline bool __static_cpu_has_safe(u16 bit)
>  	return boot_cpu_has(bit);
>  }
>  EXPORT_SYMBOL_GPL(__static_cpu_has_safe);
> +
> +static void cpu_custom_resume(void)

Let's call this bsp_resume() as it is run only on the boot CPU.

> +{
> +	if (this_cpu->c_resume)
> +		this_cpu->c_resume(&boot_cpu_data);
> +}

So giving boot_cpu_data means, this is the boot CPU but you're assigning
it to c_resume() which means, every CPU. What you could do is call the
function ptr ->c_bsp_resume like the ->c_bsp_init which we already have
so that it is clear that it is run only on the BSP.

Rest looks ok to me, unless tip guys have a better idea...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/