1. 28 2月, 2010 2 次提交
  2. 09 10月, 2009 1 次提交
  3. 16 9月, 2009 1 次提交
  4. 31 8月, 2009 3 次提交
  5. 05 8月, 2009 1 次提交
    • A
      x86: Fix VMI && stack protector · 7d5b0056
      Alok Kataria 提交于
      With CONFIG_STACK_PROTECTOR turned on, VMI doesn't boot with
      more than one processor. The problem is with the gs value not
      being initialized correctly when registering the secondary
      processor for VMI's case.
      
      The patch below initializes the gs value for the AP to
      __KERNEL_STACK_CANARY. Without this the secondary processor
      keeps on taking a GP on every gs access.
      Signed-off-by: NAlok N Kataria <akataria@vmware.com>
      Cc: <stable@kernel.org> # for v2.6.30.x
      LKML-Reference: <1249425262.18955.40.camel@ank32.eng.vmware.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7d5b0056
  6. 30 3月, 2009 2 次提交
  7. 19 3月, 2009 1 次提交
  8. 18 2月, 2009 1 次提交
  9. 17 2月, 2009 1 次提交
  10. 09 2月, 2009 1 次提交
    • A
      x86, vmi: put a missing paravirt_release_pmd in pgd_dtor · 55a8ba4b
      Alok Kataria 提交于
      Commit 6194ba6f ("x86: don't special-case
      pmd allocations as much") made changes to the way we handle pmd allocations,
      and while doing that it dropped a call to  paravirt_release_pd on the
      pgd page from the pgd_dtor code path.
      
      As a result of this missing release, the hypervisor is now unaware of the
      pgd page being freed, and as a result it ends up tracking this page as a
      page table page.
      
      After this the guest may start using the same page for other purposes, and
      depending on what use the page is put to, it may result in various performance
      and/or functional issues ( hangs, reboots).
      
      Since this release is only required for VMI, I now release the pgd page from
      the (vmi)_pgd_free hook.
      Signed-off-by: NAlok N Kataria <akataria@vmware.com>
      Acked-by: NJeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: <stable@kernel.org>
      55a8ba4b
  11. 03 2月, 2009 1 次提交
  12. 26 1月, 2009 1 次提交
    • R
      x86: fix section mismatch warning · 659d2618
      Rakib Mullick 提交于
      Here function vmi_activate calls a init function activate_vmi , which
      causes the following section mismatch warnings:
      
        LD      arch/x86/kernel/built-in.o
      WARNING: arch/x86/kernel/built-in.o(.text+0x13ba9): Section mismatch
      in reference from the function vmi_activate() to the function
      .init.text:vmi_time_init()
      The function vmi_activate() references
      the function __init vmi_time_init().
      This is often because vmi_activate lacks a __init
      annotation or the annotation of vmi_time_init is wrong.
      
      WARNING: arch/x86/kernel/built-in.o(.text+0x13bd1): Section mismatch
      in reference from the function vmi_activate() to the function
      .devinit.text:vmi_time_bsp_init()
      The function vmi_activate() references
      the function __devinit vmi_time_bsp_init().
      This is often because vmi_activate lacks a __devinit
      annotation or the annotation of vmi_time_bsp_init is wrong.
      
      WARNING: arch/x86/kernel/built-in.o(.text+0x13bdb): Section mismatch
      in reference from the function vmi_activate() to the function
      .devinit.text:vmi_time_ap_init()
      The function vmi_activate() references
      the function __devinit vmi_time_ap_init().
      This is often because vmi_activate lacks a __devinit
      annotation or the annotation of vmi_time_ap_init is wrong.
      
      Fix it by marking vmi_activate() as __init too.
      Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      659d2618
  13. 17 12月, 2008 1 次提交
    • Z
      x86: clean up dead code in vmi_32.c · fde90711
      Zachary Amsden 提交于
      Impact: cleanup, remove dead debug code
      
      I ran across some old debugging code in vmi paravirt-ops code that was
      already dead, but still potentially useful.  After reviewing recent
      changes to the way kernel page tables are allocated and initialized, and
      the lack of bugs caught by this debugging code, I've concluded it is now
      totally useless to have around, and it's already been #if 0'd for quite
      some time.
      
      There's no rush to get this in mainline, but it's also totally harmless,
      so I'll let the x86 maintainers decide where it should be tucked.  I've
      been out of the mainstream dev loop for a couple months, so apologies if
      I haven't got any protocol changes in order.
      
      Remove mummified remains found in vmi_32.c
      Signed-off-by: NZachary Amsden <zach@vmware.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fde90711
  14. 15 12月, 2008 1 次提交
  15. 01 10月, 2008 2 次提交
    • Z
      x86, vmi: fix broken LDT access · dc63b526
      Zachary Amsden 提交于
      This one took a long time to rear up because LDT usage is not very
      common, but the bug is quite serious.  It got introduced along with
      another bug, already fixed, by 75b8bb3e
      
      After investigating a JRE failure, I found this bug was introduced a long time
      ago, and had already managed to survive another bugfix which occurred on the
      same line.  The result is a total failure of the JRE due to LDT selectors not
      working properly.
      Signed-off-by: NZachary Amsden <zach@vmware.com>
      Cc: Glauber de Oliveira Costa <gcosta@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dc63b526
    • Z
      x86: Fix broken LDT access in VMI · de59985e
      Zachary Amsden 提交于
      After investigating a JRE failure, I found this bug was introduced a
      long time ago, and had already managed to survive another bugfix which
      occurred on the same line.  The result is a total failure of the JRE due
      to LDT selectors not working properly.
      
      This one took a long time to rear up because LDT usage is not very
      common, but the bug is quite serious.  It got introduced along with
      another bug, already fixed, by 75b8bb3eSigned-off-by: NZachary Amsden <zach@vmware.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Glauber de Oliveira Costa <gcosta@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      de59985e
  16. 22 8月, 2008 1 次提交
  17. 09 8月, 2008 1 次提交
  18. 19 7月, 2008 1 次提交
  19. 18 7月, 2008 1 次提交
    • M
      x86: APIC: remove apic_write_around(); use alternatives · 593f4a78
      Maciej W. Rozycki 提交于
      Use alternatives to select the workaround for the 11AP Pentium erratum
      for the affected steppings on the fly rather than build time.  Remove the
      X86_GOOD_APIC configuration option and replace all the calls to
      apic_write_around() with plain apic_write(), protecting accesses to the
      ESR as appropriate due to the 3AP Pentium erratum.  Remove
      apic_read_around() and all its invocations altogether as not needed.
      Remove apic_write_atomic() and all its implementing backends.  The use of
      ASM_OUTPUT2() is not strictly needed for input constraints, but I have
      used it for readability's sake.
      
      I had the feeling no one else was brave enough to do it, so I went ahead
      and here it is.  Verified by checking the generated assembly and tested
      with both a 32-bit and a 64-bit configuration, also with the 11AP
      "feature" forced on and verified with gdb on /proc/kcore to work as
      expected (as an 11AP machines are quite hard to get hands on these days).
      Some script complained about the use of "volatile", but apic_write() needs
      it for the same reason and is effectively a replacement for writel(), so I
      have disregarded it.
      
      I am not sure what the policy wrt defconfig files is, they are generated
      and there is risk of a conflict resulting from an unrelated change, so I
      have left changes to them out.  The option will get removed from them at
      the next run.
      
      Some testing with machines other than mine will be needed to avoid some
      stupid mistake, but despite its volume, the change is not really that
      intrusive, so I am fairly confident that because it works for me, it will
      everywhere.
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      593f4a78
  20. 14 7月, 2008 1 次提交
  21. 09 7月, 2008 1 次提交
  22. 08 7月, 2008 1 次提交
    • J
      x86/paravirt: split sysret and sysexit · d75cd22f
      Jeremy Fitzhardinge 提交于
      Don't conflate sysret and sysexit; they're different instructions with
      different semantics, and may be in use at the same time (at least
      within the same kernel, depending on whether its an Intel or AMD
      system).
      
      sysexit - just return to userspace, does no register restoration of
          any kind; must explicitly atomically enable interrupts.
      
      sysret - reloads flags from r11, so no need to explicitly enable
          interrupts on 64-bit, responsible for restoring usermode %gs
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citirx.com>
      Cc: xen-devel <xen-devel@lists.xensource.com>
      Cc: Stephen Tweedie <sct@redhat.com>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Cc: Mark McLoughlin <markmc@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d75cd22f
  23. 25 4月, 2008 2 次提交
  24. 04 2月, 2008 1 次提交
  25. 30 1月, 2008 9 次提交
  26. 17 10月, 2007 1 次提交
    • J
      paravirt: clean up lazy mode handling · 8965c1c0
      Jeremy Fitzhardinge 提交于
      Currently, the set_lazy_mode pv_op is overloaded with 5 functions:
       1. enter lazy cpu mode
       2. leave lazy cpu mode
       3. enter lazy mmu mode
       4. leave lazy mmu mode
       5. flush pending batched operations
      
      This complicates each paravirt backend, since it needs to deal with
      all the possible state transitions, handling flushing, etc. In
      particular, flushing is quite distinct from the other 4 functions, and
      seems to just cause complication.
      
      This patch removes the set_lazy_mode operation, and adds "enter" and
      "leave" lazy mode operations on mmu_ops and cpu_ops.  All the logic
      associated with enter and leaving lazy states is now in common code
      (basically BUG_ONs to make sure that no mode is current when entering
      a lazy mode, and make sure that the mode is current when leaving).
      Also, flush is handled in a common way, by simply leaving and
      re-entering the lazy mode.
      
      The result is that the Xen, lguest and VMI lazy mode implementations
      are much simpler.
      Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Zach Amsden <zach@vmware.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Avi Kivity <avi@qumranet.com>
      Cc: Anthony Liguory <aliguori@us.ibm.com>
      Cc: "Glauber de Oliveira Costa" <glommer@gmail.com>
      Cc: Jun Nakajima <jun.nakajima@intel.com>
      8965c1c0