All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Richter <robert.richter@amd.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
	Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/7] x86, xsave: introduce xstate enable functions
Date: Thu, 22 Jul 2010 14:15:22 +0200	[thread overview]
Message-ID: <20100722121522.GT26154@erda.amd.com> (raw)
In-Reply-To: <4C476C5B.8020604@zytor.com>

On 21.07.10 17:53:31, H. Peter Anvin wrote:

> From 55b936c7a359a14d72bcba6c3fceba4cfbe3fedf Mon Sep 17 00:00:00 2001
> From: H. Peter Anvin <hpa@linux.intel.com>
> Date: Wed, 21 Jul 2010 14:23:10 -0700
> Subject: [PATCH] x86, xsave: Make xstate_enable_boot_cpu() __init, protect on CPU 0
> 
> xstate_enable_boot_cpu() is, as the name implies, only used on the
> boot CPU; furthermore, it invokes alloc_bootmem(), which is __init;
> hence it needs to be tagged __init rather than __cpuinit.
> 
> Furthermore, it is *not* safe in the long run to rely on CPU 0 only
> coming online during the early boot -- at some point we're going to
> support offlining (and re-onlining) the boot CPU, and at that point we
> must not call xstate_enable_boot_cpu() again.
> 
> The code is a fair bit more obscure than one would like, because the
> __ref overrides aren't quite powerful enough.
> 
> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
> Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
> Cc: Robert Richter <robert.richter@amd.com>
> LKML-Reference: <4C476236.1020302@zytor.com>

I am fine with your changes.

>  void __cpuinit xsave_init(void)
>  {
> +	static __refdata void (*next_func)(void) = xstate_enable_boot_cpu;
> +	void (*this_func)(void);
> +
>  	if (!cpu_has_xsave)
>  		return;
>  
> -	/*
> -	 * Boot processor to setup the FP and extended state context info.
> -	 */
> -	if (!smp_processor_id())
> -		xstate_enable_boot_cpu();
> -	else
> -		xstate_enable(pcntxt_mask);
> +	this_func = next_func;
> +	next_func = xstate_enable;
> +	this_func();
>  }

Just wondering why you are using this_func()? Instead, you could
simply do:

	next_func();
	next_func = xstate_enable;

Do you see races when bringing up multiple cpus in parallel?

Thanks.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center


  parent reply	other threads:[~2010-07-22 12:15 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-21 17:03 [PATCH 0/7] x86, xsave: some code cleanups and reworks, -v2 Robert Richter
2010-07-21 17:03 ` [PATCH 1/7] x86, xsave: separate fpu and xsave initialization Robert Richter
2010-07-21 22:36   ` [tip:x86/xsave] x86, xsave: Separate " tip-bot for Robert Richter
2010-07-21 17:03 ` [PATCH 2/7] x86, xsave: introduce xstate enable functions Robert Richter
2010-07-21 21:10   ` H. Peter Anvin
2010-07-21 21:20     ` Suresh Siddha
2010-07-21 21:53       ` H. Peter Anvin
2010-07-21 22:32         ` Suresh Siddha
2010-07-22 12:15         ` Robert Richter [this message]
2010-07-22 12:23           ` H. Peter Anvin
2010-07-22 13:16             ` Robert Richter
2010-07-21 22:38     ` [tip:x86/xsave] x86, xsave: Make xstate_enable_boot_cpu() __init, protect on CPU 0 tip-bot for H. Peter Anvin
2010-07-21 22:37   ` [tip:x86/xsave] x86, xsave: Introduce xstate enable functions tip-bot for Robert Richter
2010-07-21 17:03 ` [PATCH 3/7] x86, xsave: check cpuid level for XSTATE_CPUID (0x0d) Robert Richter
2010-07-21 22:37   ` [tip:x86/xsave] x86, xsave: Check " tip-bot for Robert Richter
2010-07-21 17:03 ` [PATCH 4/7] x86, xsave: make init_xstate_buf static Robert Richter
2010-07-21 22:37   ` [tip:x86/xsave] x86, xsave: Make " tip-bot for Robert Richter
2010-07-21 17:03 ` [PATCH 5/7] x86, xsave: add __init attribute to setup_xstate_features() Robert Richter
2010-07-21 22:37   ` [tip:x86/xsave] x86, xsave: Add " tip-bot for Robert Richter
2010-07-21 17:03 ` [PATCH 6/7] x86, xsave: disable xsave in i387 emulation mode Robert Richter
2010-07-21 18:16   ` Suresh Siddha
2010-07-22 12:36     ` Robert Richter
2010-07-23 17:50       ` Suresh Siddha
2010-07-26 16:42         ` Robert Richter
2010-07-26 18:26       ` H. Peter Anvin
2010-07-27  8:53         ` Robert Richter
2010-08-12 22:06   ` [tip:x86/fpu] x86, xsave: Disable " tip-bot for Robert Richter
2010-07-21 17:03 ` [PATCH 7/7] x86: removing boot_cpu_id variable Robert Richter
2010-08-12 21:03   ` [tip:x86/cleanups] x86, cleanup: Remove obsolete " tip-bot for Robert Richter
2010-07-21 18:19 ` [PATCH 0/7] x86, xsave: some code cleanups and reworks, -v2 Suresh Siddha
2010-07-21 20:55 ` H. Peter Anvin
2010-07-21 21:07   ` H. Peter Anvin
2010-08-10 19:24 ` [osrc-patches] " Robert Richter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100722121522.GT26154@erda.amd.com \
    --to=robert.richter@amd.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=suresh.b.siddha@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.