Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1275078 > unrolled thread

lapic_suspend/lapic_resume wrong?

Back to article view | Back to linux.kernel

Contents

  lapic_suspend/lapic_resume wrong? Juergen Gross <jgross@suse.com> - 2015-11-23 08:50 +0100
    Re: lapic_suspend/lapic_resume wrong? Ingo Molnar <mingo@kernel.org> - 2015-11-23 09:10 +0100
      Re: lapic_suspend/lapic_resume wrong? Juergen Gross <jgross@suse.com> - 2015-11-23 10:40 +0100
        Re: lapic_suspend/lapic_resume wrong? Borislav Petkov <bp@suse.de> - 2015-11-23 11:00 +0100
          Re: lapic_suspend/lapic_resume wrong? Juergen Gross <jgross@suse.com> - 2015-11-23 11:00 +0100

#1275078 — lapic_suspend/lapic_resume wrong?

[Multipart message — attachments visible in raw view] — view raw

Hi,

while trying to find the reason for a hanging kernel during resume
handling I found a strange inconsistency in arch/x86/kernel/apic/apic.c
regarding usage of config options.

Attached patch addresses this, no test done as I'm not sure whether
this is a correct approach. Can you have a look at it, please?


Juergen

[toc] | [next] | [standalone]

#1275097

* Juergen Gross <jgross@suse.com> wrote:

> Hi,
> 
> while trying to find the reason for a hanging kernel during resume
> handling I found a strange inconsistency in arch/x86/kernel/apic/apic.c
> regarding usage of config options.
> 
> Attached patch addresses this, no test done as I'm not sure whether
> this is a correct approach. Can you have a look at it, please?
> 
> 
> Juergen
>
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index 2f69e3b..bc06c9d 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -2270,6 +2270,7 @@ static struct {
>  	unsigned int apic_tmict;
>  	unsigned int apic_tdcr;
>  	unsigned int apic_thmr;
> +	unsigned int apic_cmci;
>  } apic_pm_state;
>  
>  static int lapic_suspend(void)
> @@ -2299,6 +2300,10 @@ static int lapic_suspend(void)
>  	if (maxlvt >= 5)
>  		apic_pm_state.apic_thmr = apic_read(APIC_LVTTHMR);
>  #endif
> +#ifdef CONFIG_X86_MCE_INTEL
> +	if (maxlvt >= 6)
> +		apic_pm_state.apic_cmci = apic_read(APIC_LVTCMCI);
> +#endif
>  
>  	local_irq_save(flags);
>  	disable_local_APIC();
> @@ -2355,10 +2360,14 @@ static void lapic_resume(void)
>  	apic_write(APIC_SPIV, apic_pm_state.apic_spiv);
>  	apic_write(APIC_LVT0, apic_pm_state.apic_lvt0);
>  	apic_write(APIC_LVT1, apic_pm_state.apic_lvt1);
> -#if defined(CONFIG_X86_MCE_INTEL)
> +#if defined(CONFIG_X86_THERMAL_VECTOR)
>  	if (maxlvt >= 5)
>  		apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr);
>  #endif
> +#if defined(CONFIG_X86_MCE_INTEL)
> +	if (maxlvt >= 6)
> +		apic_write(APIC_LVTCMCI, apic_pm_state.apic_cmci);
> +#endif
>  	if (maxlvt >= 4)
>  		apic_write(APIC_LVTPC, apic_pm_state.apic_lvtpc);
>  	apic_write(APIC_LVTT, apic_pm_state.apic_lvtt);

the x86 bit looks absolutely sensible to me.

Have you checked whether we indeed lose this value over S/R, or is this mostly 
working fine by accident, due to us executing the CMCI vector initialization via:

  mce_syscore_resume()->__mcheck_cpu_init_vendor()->mce_intel_feature_init()->intel_init_cmci() 

on every resume event?

The Xen fix is unrelated, just put into the same patch, right?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275169

On 23/11/15 09:01, Ingo Molnar wrote:
> 
> * Juergen Gross <jgross@suse.com> wrote:
> 
>> Hi,
>>
>> while trying to find the reason for a hanging kernel during resume
>> handling I found a strange inconsistency in arch/x86/kernel/apic/apic.c
>> regarding usage of config options.
>>
>> Attached patch addresses this, no test done as I'm not sure whether
>> this is a correct approach. Can you have a look at it, please?
>>
>>
>> Juergen
>>
>> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
>> index 2f69e3b..bc06c9d 100644
>> --- a/arch/x86/kernel/apic/apic.c
>> +++ b/arch/x86/kernel/apic/apic.c
>> @@ -2270,6 +2270,7 @@ static struct {
>>  	unsigned int apic_tmict;
>>  	unsigned int apic_tdcr;
>>  	unsigned int apic_thmr;
>> +	unsigned int apic_cmci;
>>  } apic_pm_state;
>>  
>>  static int lapic_suspend(void)
>> @@ -2299,6 +2300,10 @@ static int lapic_suspend(void)
>>  	if (maxlvt >= 5)
>>  		apic_pm_state.apic_thmr = apic_read(APIC_LVTTHMR);
>>  #endif
>> +#ifdef CONFIG_X86_MCE_INTEL
>> +	if (maxlvt >= 6)
>> +		apic_pm_state.apic_cmci = apic_read(APIC_LVTCMCI);
>> +#endif
>>  
>>  	local_irq_save(flags);
>>  	disable_local_APIC();
>> @@ -2355,10 +2360,14 @@ static void lapic_resume(void)
>>  	apic_write(APIC_SPIV, apic_pm_state.apic_spiv);
>>  	apic_write(APIC_LVT0, apic_pm_state.apic_lvt0);
>>  	apic_write(APIC_LVT1, apic_pm_state.apic_lvt1);
>> -#if defined(CONFIG_X86_MCE_INTEL)
>> +#if defined(CONFIG_X86_THERMAL_VECTOR)
>>  	if (maxlvt >= 5)
>>  		apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr);
>>  #endif
>> +#if defined(CONFIG_X86_MCE_INTEL)
>> +	if (maxlvt >= 6)
>> +		apic_write(APIC_LVTCMCI, apic_pm_state.apic_cmci);
>> +#endif
>>  	if (maxlvt >= 4)
>>  		apic_write(APIC_LVTPC, apic_pm_state.apic_lvtpc);
>>  	apic_write(APIC_LVTT, apic_pm_state.apic_lvtt);
> 
> the x86 bit looks absolutely sensible to me.

Thanks. I'll give it a suspend/resume test and send out a patch.

> Have you checked whether we indeed lose this value over S/R, or is this mostly 
> working fine by accident, due to us executing the CMCI vector initialization via:
> 
>   mce_syscore_resume()->__mcheck_cpu_init_vendor()->mce_intel_feature_init()->intel_init_cmci() 
> 
> on every resume event?

I don't know. I was more concerned what might happen in a kernel
configured with CONFIG_X86_MCE_INTEL but not CONFIG_X86_THERMAL_VECTOR.
I guess on such a kernel the THMR vector could be set to zero causing
some pain (enabled, vector 0?).

> The Xen fix is unrelated, just put into the same patch, right?

Uuh, yes, sorry. Just a relict of testing another fix.


Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275186

On Mon, Nov 23, 2015 at 10:32:35AM +0100, Juergen Gross wrote:
> I don't know. I was more concerned what might happen in a kernel
> configured with CONFIG_X86_MCE_INTEL but not CONFIG_X86_THERMAL_VECTOR.

How can you even do that without patching Kconfig?

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275190

On 23/11/15 10:50, Borislav Petkov wrote:
> On Mon, Nov 23, 2015 at 10:32:35AM +0100, Juergen Gross wrote:
>> I don't know. I was more concerned what might happen in a kernel
>> configured with CONFIG_X86_MCE_INTEL but not CONFIG_X86_THERMAL_VECTOR.
> 
> How can you even do that without patching Kconfig?

I didn't check it. You are right, can't happen (today).

The code is wrong nevertheless.


Juergen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web