All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Shane Wang <shane.wang@intel.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"arjan@linux.intel.com" <arjan@linux.intel.com>,
	"chrisw@sous-sol.org" <chrisw@sous-sol.org>,
	"jmorris@namei.org" <jmorris@namei.org>,
	"jbeulich@novell.com" <jbeulich@novell.com>,
	"peterm@redhat.com" <peterm@redhat.com>,
	"Wei, Gang" <gang.wei@intel.com>
Subject: Re: [PATCH] txt: fix the build errors on non-X86 platforms
Date: Fri, 21 Aug 2009 15:50:50 +0200	[thread overview]
Message-ID: <20090821135050.GA30346@elte.hu> (raw)
In-Reply-To: <4A8E9B3C.5070604@intel.com>


* Shane Wang <shane.wang@intel.com> wrote:

> This patch moves tboot.h from asm to linux to fix the build errors 
> on non-X86 platforms.
>
> Signed-off-by: Shane Wang <shane.wang@intel.com>
>
>
> diff -r 04f249f00303 arch/x86/include/asm/tboot.h

[ small nit: please always generate diffstat information for your 
  patches as well, so that one can see which files are changed and 
  by how much. ]

This patch looks better, but i have to question why tboot modifies 
generic code at all.

i've attached those generic-code changes below. The init/main.c one 
could sure be done in x86 arch init code, or via an initcall, right? 

Regarding kernel/cpu.c. Tthis code in tboot_wait_for_aps() looks 
suspicious:

int tboot_wait_for_aps(int num_aps)
{
        unsigned long timeout;

        if (!tboot_enabled())
                return 0;

        timeout = jiffies + AP_WAIT_TIMEOUT*HZ;
        while (atomic_read((atomic_t *)&tboot->num_in_wfs) != num_aps &&
               time_before(jiffies, timeout))
                cpu_relax();

        return time_before(jiffies, timeout) ? 0 : 1;
}

the return code looks a bit racy - what if an AP came back just in 
the final moment. It should return whether num_in_wfs == num_aps.

But more importantly, why does this have to be done in generic code 
in kernel/smp.c? Why doesnt the x86 arch level bit of _cpu_down() 
check whether the CPU goes down. (or, if there's no proper 
signalling for that one in the tboot protocol - the _cpu_down() code 
in x86 could call tboot_wait_for_aps() if num_online_cpus() == 1 - 
no need to change generic code here.

Also, as i pointed it out in prior review, this depends on line:

+config INTEL_TXT
+       bool "Enable Intel(R) Trusted Execution Technology (Intel(R) TXT)"
+       depends on EXPERIMENTAL && X86 && DMAR && ACPI

should be turned into the standard:

	depends on HAVE_INTEL_TXT 

line, where arch/x86/Kconfig selects HAVE_INTEL_TXT. As we do it for 
other options as well.

	Ingo

---------------->

 init/main.c  |    3 +++
 kernel/cpu.c |    7 ++++++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/init/main.c b/init/main.c
index 2d9d6bd..f8e9124 100644
--- a/init/main.c
+++ b/init/main.c
@@ -73,6 +73,7 @@
 #include <asm/io.h>
 #include <asm/bugs.h>
 #include <asm/setup.h>
+#include <asm/tboot.h>
 #include <asm/sections.h>
 #include <asm/cacheflush.h>
 
@@ -715,6 +716,8 @@ asmlinkage void __init start_kernel(void)
 
 	ftrace_init();
 
+	tboot_create_trampoline();
+
 	/* Do the rest non-__init'ed, we're now alive */
 	rest_init();
 }
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 8ce1004..ff071e0 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -14,6 +14,7 @@
 #include <linux/kthread.h>
 #include <linux/stop_machine.h>
 #include <linux/mutex.h>
+#include <asm/tboot.h>
 
 #ifdef CONFIG_SMP
 /* Serializes the updates to cpu_online_mask, cpu_present_mask */
@@ -376,7 +377,7 @@ static cpumask_var_t frozen_cpus;
 
 int disable_nonboot_cpus(void)
 {
-	int cpu, first_cpu, error;
+	int cpu, first_cpu, error, num_cpus = 0;
 
 	error = stop_machine_create();
 	if (error)
@@ -391,6 +392,7 @@ int disable_nonboot_cpus(void)
 	for_each_online_cpu(cpu) {
 		if (cpu == first_cpu)
 			continue;
+		num_cpus++;
 		error = _cpu_down(cpu, 1);
 		if (!error) {
 			cpumask_set_cpu(cpu, frozen_cpus);
@@ -401,6 +403,9 @@ int disable_nonboot_cpus(void)
 			break;
 		}
 	}
+	/* ensure all CPUs have gone into wait-for-SIPI */
+	error |= tboot_wait_for_aps(num_cpus);
+
 	if (!error) {
 		BUG_ON(num_online_cpus() > 1);
 		/* Make sure the CPUs won't be enabled by someone else */

  reply	other threads:[~2009-08-21 13:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-01  2:31 [RFC v6][PATCH 2/4] intel_txt: Intel(R) TXT reboot/halt shutdown support Joseph Cihula
2009-08-17 15:40 ` Ingo Molnar
2009-08-17 15:53   ` Ingo Molnar
2009-08-20  9:33     ` Wang, Shane
2009-08-20 16:05       ` H. Peter Anvin
2009-08-20 16:10       ` Andi Kleen
2009-08-21 13:03         ` [PATCH] txt: fix the build errors on non-X86 platforms Shane Wang
2009-08-21 13:50           ` Ingo Molnar [this message]
2009-08-21 15:23             ` [PATCH] intel_txt: fix the build errors of intel_txt patch " Shane Wang
2009-08-21 16:12               ` Ingo Molnar
2009-08-21 17:23                 ` H. Peter Anvin
2009-08-24  8:20                   ` Wang, Shane
2009-08-24  8:48                     ` Ingo Molnar
2009-08-26  6:51                       ` Shane Wang

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=20090821135050.GA30346@elte.hu \
    --to=mingo@elte.hu \
    --cc=andi@firstfloor.org \
    --cc=arjan@linux.intel.com \
    --cc=chrisw@sous-sol.org \
    --cc=gang.wei@intel.com \
    --cc=hpa@zytor.com \
    --cc=jbeulich@novell.com \
    --cc=jmorris@namei.org \
    --cc=joseph.cihula@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterm@redhat.com \
    --cc=shane.wang@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.