Eric Lee / smarc-fsl-linux-kernel

26 Mar, 2009

1 commit

  • 70511134f   Revert "x86: don't compile vsmp_64 for 32bit" ... Browse Code »

    Partial revert of commit 129d8bc828e011bda0b7110a097bf3a0167f966e
    titled 'x86: don't compile vsmp_64 for 32bit'

    Commit reverted to compile vsmp_64.c if CONFIG_X86_64 is defined,
    since is_vsmp_box() needs to indicate that TSCs are not synchronized, and
    hence, not a valid time source, even when CONFIG_X86_VSMP is not defined.

    Signed-off-by: Ravikiran Thirumalai
    Cc: Yinghai Lu
    Cc: Andrew Morton
    Cc: shai@scalex86.org
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Ravikiran G Thirumalai
     

26 Feb, 2009

1 commit

  • 129d8bc82   x86: don't compile vsmp_64 for 32bit ... Browse Code »

    Impact: cleanup

    that is only needed when CONFIG_X86_VSMP is defined with 64bit
    also remove dead code about PCI, because CONFIG_X86_VSMP depends on PCI

    Signed-off-by: Yinghai Lu
    Cc: Ravikiran Thirumalai
    Signed-off-by: Ingo Molnar

    Yinghai Lu
     

31 Jan, 2009

1 commit

  • ecb93d1cc   x86/paravirt: add register-saving thunks to reduce caller register pressure ... Browse Code »

    Impact: Optimization

    One of the problems with inserting a pile of C calls where previously
    there were none is that the register pressure is greatly increased.
    The C calling convention says that the caller must expect a certain
    set of registers may be trashed by the callee, and that the callee can
    use those registers without restriction. This includes the function
    argument registers, and several others.

    This patch seeks to alleviate this pressure by introducing wrapper
    thunks that will do the register saving/restoring, so that the
    callsite doesn't need to worry about it, but the callee function can
    be conventional compiler-generated code. In many cases (particularly
    performance-sensitive cases) the callee will be in assembler anyway,
    and need not use the compiler's calling convention.

    Standard calling convention is:
    arguments return scratch
    x86-32 eax edx ecx eax ?
    x86-64 rdi rsi rdx rcx rax r8 r9 r10 r11

    The thunk preserves all argument and scratch registers. The return
    register is not preserved, and is available as a scratch register for
    unwrapped callee code (and of course the return value).

    Wrapped function pointers are themselves wrapped in a struct
    paravirt_callee_save structure, in order to get some warning from the
    compiler when functions with mismatched calling conventions are used.

    The most common paravirt ops, both statically and dynamically, are
    interrupt enable/disable/save/restore, so handle them first. This is
    particularly easy since their calls are handled specially anyway.

    XXX Deal with VMI. What's their calling convention?

    Signed-off-by: H. Peter Anvin

    Jeremy Fitzhardinge
     

29 Oct, 2008

1 commit

  • 9352f5698   x86: two trivial sparse annotations ... Browse Code »

    Impact: fewer sparse warnings, no functional changes

    arch/x86/kernel/vsmp_64.c:87:14: warning: incorrect type in argument 1 (different address spaces)
    arch/x86/kernel/vsmp_64.c:87:14: expected void const volatile [noderef] *addr
    arch/x86/kernel/vsmp_64.c:87:14: got void *[assigned] address
    arch/x86/kernel/vsmp_64.c:88:22: warning: incorrect type in argument 1 (different address spaces)
    arch/x86/kernel/vsmp_64.c:88:22: expected void const volatile [noderef] *addr
    arch/x86/kernel/vsmp_64.c:88:22: got void *
    arch/x86/kernel/vsmp_64.c:100:23: warning: incorrect type in argument 2 (different address spaces)
    arch/x86/kernel/vsmp_64.c:100:23: expected void volatile [noderef] *addr
    arch/x86/kernel/vsmp_64.c:100:23: got void *
    arch/x86/kernel/vsmp_64.c:101:23: warning: incorrect type in argument 1 (different address spaces)
    arch/x86/kernel/vsmp_64.c:101:23: expected void const volatile [noderef] *addr
    arch/x86/kernel/vsmp_64.c:101:23: got void *
    arch/x86/mm/gup.c:235:6: warning: incorrect type in argument 1 (different base types)
    arch/x86/mm/gup.c:235:6: expected void const volatile [noderef] *
    arch/x86/mm/gup.c:235:6: got unsigned long [unsigned] [assigned] start

    Signed-off-by: Harvey Harrison
    Signed-off-by: Ingo Molnar

    Harvey Harrison
     

23 Sep, 2008

1 commit

  • 05e12e1c4   x86: fix 27-rc crash on vsmp due to paravirt during module load ... Browse Code »

    27-rc fails to boot up if configured to use modules.

    Turns out vsmp_patch was marked __init, and vsmp_patch being the
    pvops 'patch' routine for vsmp, a call to vsmp_patch just turns out
    to execute a code page with series of 0xcc (POISON_FREE_INITMEM -- int3).

    vsmp_patch has been marked with __init ever since pvops, however,
    apply_paravirt can be called during module load causing calls to
    freed memory location.

    Since apply_paravirt can only be called during init/module load, make
    vsmp_patch with "__init_or_module"

    Signed-off-by: Ravikiran Thirumalai
    Signed-off-by: Ingo Molnar

    Ravikiran G Thirumalai
     

25 May, 2008

1 commit

  • eef8f871d   x86: vsmp_64 add missing includes ... Browse Code »

    sparse mutters:
    arch/x86/kernel/vsmp_64.c:126:5: warning: symbol 'is_vsmp_box' was not declared. Should it be static?
    arch/x86/kernel/vsmp_64.c:145:13: warning: symbol 'vsmp_init' was not declared. Should it be static?

    Include the appropriate headers.

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar

    Thomas Gleixner
     

29 Apr, 2008

1 commit

17 Apr, 2008

10 commits

30 Jan, 2008

1 commit

11 Oct, 2007

1 commit