2007-12-18 20:08:39

by Glauber Costa

[permalink] [raw]
Subject: [PATCH] finish processor.h integration

What's left in processor_32.h and processor_64.h cannot be cleanly
integrated. However, it's just a couple of definitions. They are moved
to processor.h around ifdefs, and the original files are deleted. Note that
there's much less headers included in the final version.

Signed-off-by: Glauber de Oliveira Costa <[email protected]>
---
include/asm-x86/processor.h | 140 ++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 137 insertions(+), 3 deletions(-)

diff --git a/include/asm-x86/processor.h b/include/asm-x86/processor.h
index 80c5002..0641d0e 100644
--- a/include/asm-x86/processor.h
+++ b/include/asm-x86/processor.h
@@ -7,12 +7,24 @@
struct task_struct;
struct mm_struct;

+#include <asm/vm86.h>
+#include <asm/math_emu.h>
+#include <asm/segment.h>
#include <asm/page.h>
-#include <asm/percpu.h>
+#include <asm/types.h>
+#include <asm/sigcontext.h>
+#include <asm/current.h>
+#include <asm/cpufeature.h>
#include <asm/system.h>
+#include <asm/page.h>
#include <asm/percpu.h>
+#include <asm/msr.h>
+#include <asm/desc_defs.h>
+#include <linux/personality.h>
#include <linux/cpumask.h>
#include <linux/cache.h>
+#include <linux/threads.h>
+#include <linux/init.h>

/*
* Default implementation of macro that returns current
@@ -275,7 +287,11 @@ union i387_union {
struct i387_soft_struct soft;
};

-# include "processor_32.h"
+/*
+ * the following now lives in the per cpu area:
+ * extern int cpu_llc_id[NR_CPUS];
+ */
+DECLARE_PER_CPU(u8, cpu_llc_id);
#else
struct i387_fxsave_struct {
u16 cwd;
@@ -295,7 +311,7 @@ union i387_union {
struct i387_fxsave_struct fxsave;
};

-# include "processor_64.h"
+DECLARE_PER_CPU(struct orig_ist, orig_ist);
#endif

extern void print_cpu_info(struct cpuinfo_x86 *);
@@ -778,6 +794,124 @@ static inline void prefetchw(const void *x)
}

#define spin_lock_prefetch(x) prefetchw(x)
+#ifdef CONFIG_X86_32
+/*
+ * User space process size: 3GB (default).
+ */
+#define TASK_SIZE (PAGE_OFFSET)
+
+#define INIT_THREAD { \
+ .sp0 = sizeof(init_stack) + (long)&init_stack, \
+ .vm86_info = NULL, \
+ .sysenter_cs = __KERNEL_CS, \
+ .io_bitmap_ptr = NULL, \
+ .fs = __KERNEL_PERCPU, \
+}
+
+/*
+ * Note that the .io_bitmap member must be extra-big. This is because
+ * the CPU will access an additional byte beyond the end of the IO
+ * permission bitmap. The extra byte must be all 1 bits, and must
+ * be within the limit.
+ */
+#define INIT_TSS { \
+ .x86_tss = { \
+ .sp0 = sizeof(init_stack) + (long)&init_stack, \
+ .ss0 = __KERNEL_DS, \
+ .ss1 = __KERNEL_CS, \
+ .io_bitmap_base = INVALID_IO_BITMAP_OFFSET, \
+ }, \
+ .io_bitmap = { [0 ... IO_BITMAP_LONGS] = ~0 }, \
+}
+
+#define start_thread(regs, new_eip, new_esp) do { \
+ __asm__("movl %0,%%gs": :"r" (0)); \
+ regs->fs = 0; \
+ set_fs(USER_DS); \
+ regs->ds = __USER_DS; \
+ regs->es = __USER_DS; \
+ regs->ss = __USER_DS; \
+ regs->cs = __USER_CS; \
+ regs->ip = new_eip; \
+ regs->sp = new_esp; \
+} while (0)
+
+
+extern unsigned long thread_saved_pc(struct task_struct *tsk);
+
+#define THREAD_SIZE_LONGS (THREAD_SIZE/sizeof(unsigned long))
+#define KSTK_TOP(info) \
+({ \
+ unsigned long *__ptr = (unsigned long *)(info); \
+ (unsigned long)(&__ptr[THREAD_SIZE_LONGS]); \
+})
+
+/*
+ * The below -8 is to reserve 8 bytes on top of the ring0 stack.
+ * This is necessary to guarantee that the entire "struct pt_regs"
+ * is accessable even if the CPU haven't stored the SS/ESP registers
+ * on the stack (interrupt gate does not save these registers
+ * when switching to the same priv ring).
+ * Therefore beware: accessing the ss/esp fields of the
+ * "struct pt_regs" is possible, but they may contain the
+ * completely wrong values.
+ */
+#define task_pt_regs(task) \
+({ \
+ struct pt_regs *__regs__; \
+ __regs__ = (struct pt_regs *)(KSTK_TOP(task_stack_page(task))-8); \
+ __regs__ - 1; \
+})
+
+#define KSTK_ESP(task) (task_pt_regs(task)->sp)
+
+#else
+/*
+ * User space process size. 47bits minus one guard page.
+ */
+#define TASK_SIZE64 (0x800000000000UL - 4096)
+
+/* This decides where the kernel will search for a free chunk of vm
+ * space during mmap's.
+ */
+#define IA32_PAGE_OFFSET ((current->personality & ADDR_LIMIT_3GB) ? \
+ 0xc0000000 : 0xFFFFe000)
+
+#define TASK_SIZE (test_thread_flag(TIF_IA32) ? \
+ IA32_PAGE_OFFSET : TASK_SIZE64)
+#define TASK_SIZE_OF(child) ((test_tsk_thread_flag(child, TIF_IA32)) ? \
+ IA32_PAGE_OFFSET : TASK_SIZE64)
+
+#define INIT_THREAD { \
+ .sp0 = (unsigned long)&init_stack + sizeof(init_stack) \
+}
+
+#define INIT_TSS { \
+ .x86_tss.sp0 = (unsigned long)&init_stack + sizeof(init_stack) \
+}
+
+#define start_thread(regs, new_rip, new_rsp) do { \
+ asm volatile("movl %0,%%fs; movl %0,%%es; movl %0,%%ds": :"r" (0)); \
+ load_gs_index(0); \
+ (regs)->ip = (new_rip); \
+ (regs)->sp = (new_rsp); \
+ write_pda(oldrsp, (new_rsp)); \
+ (regs)->cs = __USER_CS; \
+ (regs)->ss = __USER_DS; \
+ (regs)->flags = 0x200; \
+ set_fs(USER_DS); \
+} while (0)
+
+/*
+ * Return saved PC of a blocked thread.
+ * What is this good for? it will be always the scheduler or ret_from_fork.
+ */
+#define thread_saved_pc(t) (*(unsigned long *)((t)->thread.sp - 8))
+
+#define task_pt_regs(tsk) ((struct pt_regs *)(tsk)->thread.sp0 - 1)
+#define KSTK_ESP(tsk) -1 /* sorry. doesn't work for syscall. */
+#endif /* CONFIG_X86_64 */
+
/* This decides where the kernel will search for a free chunk of vm
* space during mmap's.
*/
--
1.5.0.6


2007-12-18 20:55:03

by Frans Pop

[permalink] [raw]
Subject: Re: [PATCH] finish processor.h integration

Glauber de Oliveira Costa wrote:
> What's left in processor_32.h and processor_64.h cannot be cleanly
> integrated. However, it's just a couple of definitions. They are moved
> to processor.h around ifdefs, and the original files are deleted. Note
> that there's much less headers included in the final version.

Either I must be missing something or this patch was corrupted somehow.

I see:

+#ifdef CONFIG_X86_32
[...]
+#endif /* CONFIG_X86_64 */

While I'd have expected:

+#ifdef CONFIG_X86_32
[...]
+#endif /* CONFIG_X86_32 */
+
+#ifdef CONFIG_X86_64
[...]
+#endif /* CONFIG_X86_64 */

Cheers,
FJP

2007-12-18 21:00:46

by Glauber Costa

[permalink] [raw]
Subject: Re: [PATCH] finish processor.h integration

On Dec 18, 2007 6:54 PM, Frans Pop <[email protected]> wrote:
> Glauber de Oliveira Costa wrote:
> > What's left in processor_32.h and processor_64.h cannot be cleanly
> > integrated. However, it's just a couple of definitions. They are moved
> > to processor.h around ifdefs, and the original files are deleted. Note
> > that there's much less headers included in the final version.
>
> Either I must be missing something or this patch was corrupted somehow.

neither.
Note the else in the middle. It's just a mistake in the comment.
Ingo, do you want me to send an update with it ?

--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

2007-12-18 21:04:01

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] finish processor.h integration


* Glauber de Oliveira Costa <[email protected]> wrote:

> On Dec 18, 2007 6:54 PM, Frans Pop <[email protected]> wrote:
> > Glauber de Oliveira Costa wrote:
> > > What's left in processor_32.h and processor_64.h cannot be cleanly
> > > integrated. However, it's just a couple of definitions. They are moved
> > > to processor.h around ifdefs, and the original files are deleted. Note
> > > that there's much less headers included in the final version.
> >
> > Either I must be missing something or this patch was corrupted somehow.
>
> neither.
> Note the else in the middle. It's just a mistake in the comment.
> Ingo, do you want me to send an update with it ?

no need, i'll pick up the current patches.

Ingo

2007-12-18 21:32:59

by Frans Pop

[permalink] [raw]
Subject: Re: [PATCH] finish processor.h integration

On Tuesday 18 December 2007, Glauber de Oliveira Costa wrote:
> On Dec 18, 2007 6:54 PM, Frans Pop <[email protected]> wrote:
> > Glauber de Oliveira Costa wrote:
> > > What's left in processor_32.h and processor_64.h cannot be cleanly
> > > integrated. However, it's just a couple of definitions. They are
> > > moved to processor.h around ifdefs, and the original files are
> > > deleted. Note that there's much less headers included in the final
> > > version.
> >
> > Either I must be missing something or this patch was corrupted somehow.
>
> neither.
> Note the else in the middle. It's just a mistake in the comment.

Wouldn't an explicit second #ifdef block be a lot clearer (and improve
maintainability) in this case?

An #else can easily be overlooked among other preprocessor commands or when
#ifdefs get nested.

2007-12-19 02:56:17

by Glauber Costa

[permalink] [raw]
Subject: Re: [PATCH] finish processor.h integration

On Dec 18, 2007 7:32 PM, Frans Pop <[email protected]> wrote:
> On Tuesday 18 December 2007, Glauber de Oliveira Costa wrote:
> > On Dec 18, 2007 6:54 PM, Frans Pop <[email protected]> wrote:
> > > Glauber de Oliveira Costa wrote:
> > > > What's left in processor_32.h and processor_64.h cannot be cleanly
> > > > integrated. However, it's just a couple of definitions. They are
> > > > moved to processor.h around ifdefs, and the original files are
> > > > deleted. Note that there's much less headers included in the final
> > > > version.
> > >
> > > Either I must be missing something or this patch was corrupted somehow.
> >
> > neither.
> > Note the else in the middle. It's just a mistake in the comment.
>
> Wouldn't an explicit second #ifdef block be a lot clearer (and improve
> maintainability) in this case?
>
> An #else can easily be overlooked among other preprocessor commands or when
> #ifdefs get nested.
>
I don't think so. a if-then-else kind of construction is very common,
well expected, and heavily used in kernel.
But even if I?m not right, this is functionally correct, and can be
addressed in a later cleanup patch if you really want to.


--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

2007-12-19 10:18:51

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] finish processor.h integration


* Glauber de Oliveira Costa <[email protected]> wrote:

> What's left in processor_32.h and processor_64.h cannot be cleanly
> integrated. However, it's just a couple of definitions. They are moved
> to processor.h around ifdefs, and the original files are deleted. Note
> that there's much less headers included in the final version.

hm, doesnt apply;

Applying patch patches/x86-finish-processor-h-integration.patch
patching file include/asm-x86/processor.h
Hunk #2 FAILED at 287.
Hunk #3 FAILED at 311.
Hunk #4 succeeded at 786 (offset -8 lines).
2 out of 4 hunks FAILED -- rejects in file include/asm-x86/processor.h

i fixed it up by hand - the result is below - does it look OK to you?
(Also, could you check latest x86.git whether i've picked up all your
patches correctly - the reject might be indicative of some missing
pieces.)

Ingo

------------>
Subject: finish processor.h integration
From: Glauber de Oliveira Costa <[email protected]>

What's left in processor_32.h and processor_64.h cannot be cleanly
integrated. However, it's just a couple of definitions. They are moved
to processor.h around ifdefs, and the original files are deleted. Note that
there's much less headers included in the final version.

Signed-off-by: Glauber de Oliveira Costa <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
---
include/asm-x86/processor.h | 140 +++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 137 insertions(+), 3 deletions(-)

Index: linux-x86.q/include/asm-x86/processor.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/processor.h
+++ linux-x86.q/include/asm-x86/processor.h
@@ -7,12 +7,24 @@
struct task_struct;
struct mm_struct;

+#include <asm/vm86.h>
+#include <asm/math_emu.h>
+#include <asm/segment.h>
#include <asm/page.h>
-#include <asm/percpu.h>
+#include <asm/types.h>
+#include <asm/sigcontext.h>
+#include <asm/current.h>
+#include <asm/cpufeature.h>
#include <asm/system.h>
+#include <asm/page.h>
#include <asm/percpu.h>
+#include <asm/msr.h>
+#include <asm/desc_defs.h>
+#include <linux/personality.h>
#include <linux/cpumask.h>
#include <linux/cache.h>
+#include <linux/threads.h>
+#include <linux/init.h>

/*
* Default implementation of macro that returns current
@@ -285,9 +297,13 @@ union i387_union {
};

#ifdef CONFIG_X86_32
-# include "processor_32.h"
+/*
+ * the following now lives in the per cpu area:
+ * extern int cpu_llc_id[NR_CPUS];
+ */
+DECLARE_PER_CPU(u8, cpu_llc_id);
#else
-# include "processor_64.h"
+DECLARE_PER_CPU(struct orig_ist, orig_ist);
#endif

extern void print_cpu_info(struct cpuinfo_x86 *);
@@ -770,6 +786,124 @@ static inline void prefetchw(const void
}

#define spin_lock_prefetch(x) prefetchw(x)
+#ifdef CONFIG_X86_32
+/*
+ * User space process size: 3GB (default).
+ */
+#define TASK_SIZE (PAGE_OFFSET)
+
+#define INIT_THREAD { \
+ .sp0 = sizeof(init_stack) + (long)&init_stack, \
+ .vm86_info = NULL, \
+ .sysenter_cs = __KERNEL_CS, \
+ .io_bitmap_ptr = NULL, \
+ .fs = __KERNEL_PERCPU, \
+}
+
+/*
+ * Note that the .io_bitmap member must be extra-big. This is because
+ * the CPU will access an additional byte beyond the end of the IO
+ * permission bitmap. The extra byte must be all 1 bits, and must
+ * be within the limit.
+ */
+#define INIT_TSS { \
+ .x86_tss = { \
+ .sp0 = sizeof(init_stack) + (long)&init_stack, \
+ .ss0 = __KERNEL_DS, \
+ .ss1 = __KERNEL_CS, \
+ .io_bitmap_base = INVALID_IO_BITMAP_OFFSET, \
+ }, \
+ .io_bitmap = { [0 ... IO_BITMAP_LONGS] = ~0 }, \
+}
+
+#define start_thread(regs, new_eip, new_esp) do { \
+ __asm__("movl %0,%%gs": :"r" (0)); \
+ regs->fs = 0; \
+ set_fs(USER_DS); \
+ regs->ds = __USER_DS; \
+ regs->es = __USER_DS; \
+ regs->ss = __USER_DS; \
+ regs->cs = __USER_CS; \
+ regs->ip = new_eip; \
+ regs->sp = new_esp; \
+} while (0)
+
+
+extern unsigned long thread_saved_pc(struct task_struct *tsk);
+
+#define THREAD_SIZE_LONGS (THREAD_SIZE/sizeof(unsigned long))
+#define KSTK_TOP(info) \
+({ \
+ unsigned long *__ptr = (unsigned long *)(info); \
+ (unsigned long)(&__ptr[THREAD_SIZE_LONGS]); \
+})
+
+/*
+ * The below -8 is to reserve 8 bytes on top of the ring0 stack.
+ * This is necessary to guarantee that the entire "struct pt_regs"
+ * is accessable even if the CPU haven't stored the SS/ESP registers
+ * on the stack (interrupt gate does not save these registers
+ * when switching to the same priv ring).
+ * Therefore beware: accessing the ss/esp fields of the
+ * "struct pt_regs" is possible, but they may contain the
+ * completely wrong values.
+ */
+#define task_pt_regs(task) \
+({ \
+ struct pt_regs *__regs__; \
+ __regs__ = (struct pt_regs *)(KSTK_TOP(task_stack_page(task))-8); \
+ __regs__ - 1; \
+})
+
+#define KSTK_ESP(task) (task_pt_regs(task)->sp)
+
+#else
+/*
+ * User space process size. 47bits minus one guard page.
+ */
+#define TASK_SIZE64 (0x800000000000UL - 4096)
+
+/* This decides where the kernel will search for a free chunk of vm
+ * space during mmap's.
+ */
+#define IA32_PAGE_OFFSET ((current->personality & ADDR_LIMIT_3GB) ? \
+ 0xc0000000 : 0xFFFFe000)
+
+#define TASK_SIZE (test_thread_flag(TIF_IA32) ? \
+ IA32_PAGE_OFFSET : TASK_SIZE64)
+#define TASK_SIZE_OF(child) ((test_tsk_thread_flag(child, TIF_IA32)) ? \
+ IA32_PAGE_OFFSET : TASK_SIZE64)
+
+#define INIT_THREAD { \
+ .sp0 = (unsigned long)&init_stack + sizeof(init_stack) \
+}
+
+#define INIT_TSS { \
+ .x86_tss.sp0 = (unsigned long)&init_stack + sizeof(init_stack) \
+}
+
+#define start_thread(regs, new_rip, new_rsp) do { \
+ asm volatile("movl %0,%%fs; movl %0,%%es; movl %0,%%ds": :"r" (0)); \
+ load_gs_index(0); \
+ (regs)->ip = (new_rip); \
+ (regs)->sp = (new_rsp); \
+ write_pda(oldrsp, (new_rsp)); \
+ (regs)->cs = __USER_CS; \
+ (regs)->ss = __USER_DS; \
+ (regs)->flags = 0x200; \
+ set_fs(USER_DS); \
+} while (0)
+
+/*
+ * Return saved PC of a blocked thread.
+ * What is this good for? it will be always the scheduler or ret_from_fork.
+ */
+#define thread_saved_pc(t) (*(unsigned long *)((t)->thread.sp - 8))
+
+#define task_pt_regs(tsk) ((struct pt_regs *)(tsk)->thread.sp0 - 1)
+#define KSTK_ESP(tsk) -1 /* sorry. doesn't work for syscall. */
+#endif /* CONFIG_X86_64 */
+
/* This decides where the kernel will search for a free chunk of vm
* space during mmap's.
*/

2007-12-19 12:15:42

by Glauber Costa

[permalink] [raw]
Subject: Re: [PATCH] finish processor.h integration

On Dec 19, 2007 8:17 AM, Ingo Molnar <[email protected]> wrote:
>
> * Glauber de Oliveira Costa <[email protected]> wrote:
>
> > What's left in processor_32.h and processor_64.h cannot be cleanly
> > integrated. However, it's just a couple of definitions. They are moved
> > to processor.h around ifdefs, and the original files are deleted. Note
> > that there's much less headers included in the final version.
>
> hm, doesnt apply;
>
> Applying patch patches/x86-finish-processor-h-integration.patch
> patching file include/asm-x86/processor.h
> Hunk #2 FAILED at 287.
> Hunk #3 FAILED at 311.
> Hunk #4 succeeded at 786 (offset -8 lines).
> 2 out of 4 hunks FAILED -- rejects in file include/asm-x86/processor.h
>
> i fixed it up by hand - the result is below - does it look OK to you?
> (Also, could you check latest x86.git whether i've picked up all your
> patches correctly - the reject might be indicative of some missing
> pieces.)

Your fix is okay. The other patches seems to be all there. The reason
for this is that
it conflicts with Roland's (welcome) i387 patches.


--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

2007-12-19 13:46:51

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] finish processor.h integration


* Glauber de Oliveira Costa <[email protected]> wrote:

> > i fixed it up by hand - the result is below - does it look OK to
> > you? (Also, could you check latest x86.git whether i've picked up
> > all your patches correctly - the reject might be indicative of some
> > missing pieces.)
>
> Your fix is okay. The other patches seems to be all there. The reason
> for this is that it conflicts with Roland's (welcome) i387 patches.

ah, indeed - i forgot about that interaction. Your patches passed a
few hundred random builds and bootups meanwhile so i think they are
now 100% Perfect (tm) :-)

Ingo