1. 15 2月, 2012 1 次提交
  2. 01 2月, 2012 2 次提交
    • S
      KVM: x86: fix missing checks in syscall emulation · c2226fc9
      Stephan Bärwolf 提交于
      On hosts without this patch, 32bit guests will crash (and 64bit guests
      may behave in a wrong way) for example by simply executing following
      nasm-demo-application:
      
          [bits 32]
          global _start
          SECTION .text
          _start: syscall
      
      (I tested it with winxp and linux - both always crashed)
      
          Disassembly of section .text:
      
          00000000 <_start>:
             0:   0f 05                   syscall
      
      The reason seems a missing "invalid opcode"-trap (int6) for the
      syscall opcode "0f05", which is not available on Intel CPUs
      within non-longmodes, as also on some AMD CPUs within legacy-mode.
      (depending on CPU vendor, MSR_EFER and cpuid)
      
      Because previous mentioned OSs may not engage corresponding
      syscall target-registers (STAR, LSTAR, CSTAR), they remain
      NULL and (non trapping) syscalls are leading to multiple
      faults and finally crashs.
      
      Depending on the architecture (AMD or Intel) pretended by
      guests, various checks according to vendor's documentation
      are implemented to overcome the current issue and behave
      like the CPUs physical counterparts.
      
      [mtosatti: cleanup/beautify code]
      Signed-off-by: NStephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      c2226fc9
    • S
      KVM: x86: extend "struct x86_emulate_ops" with "get_cpuid" · bdb42f5a
      Stephan Bärwolf 提交于
      In order to be able to proceed checks on CPU-specific properties
      within the emulator, function "get_cpuid" is introduced.
      With "get_cpuid" it is possible to virtually call the guests
      "cpuid"-opcode without changing the VM's context.
      
      [mtosatti: cleanup/beautify code]
      Signed-off-by: NStephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      bdb42f5a
  3. 27 1月, 2012 1 次提交
  4. 26 1月, 2012 2 次提交
  5. 20 1月, 2012 1 次提交
  6. 17 1月, 2012 4 次提交
  7. 16 1月, 2012 1 次提交
  8. 13 1月, 2012 1 次提交
  9. 10 1月, 2012 1 次提交
  10. 08 1月, 2012 1 次提交
  11. 07 1月, 2012 4 次提交
    • K
      x86/PCI: Expand the x86_msi_ops to have a restore MSIs. · 76ccc297
      Konrad Rzeszutek Wilk 提交于
      The MSI restore function will become a function pointer in an
      x86_msi_ops struct. It defaults to the implementation in the
      io_apic.c and msi.c. We piggyback on the indirection mechanism
      introduced by "x86: Introduce x86_msi_ops".
      
      Cc: x86@kernel.org
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: linux-pci@vger.kernel.org
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      76ccc297
    • B
      x86/PCI: amd: factor out MMCONFIG discovery · 24d25dbf
      Bjorn Helgaas 提交于
      This factors out the AMD native MMCONFIG discovery so we can use it
      outside amd_bus.c.
      
      amd_bus.c reads AMD MSRs so it can remove the MMCONFIG area from the
      PCI resources.  We may also need the MMCONFIG information to work
      around BIOS defects in the ACPI MCFG table.
      
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: stable@kernel.org       # 2.6.34+
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      24d25dbf
    • B
      x86/PCI: convert to pci_create_root_bus() and pci_scan_root_bus() · 2cd6975a
      Bjorn Helgaas 提交于
      x86 has two kinds of PCI root bus scanning:
      
      (1) ACPI-based, using _CRS resources.  This used pci_create_bus(), not
          pci_scan_bus(), because ACPI hotplug needed to split the
          pci_bus_add_devices() into a separate host bridge .start() method.
      
          This patch parses the _CRS resources earlier, so we can build a list of
          resources and pass it to pci_create_root_bus().
      
          Note that as before, we parse the _CRS even if we aren't going to use
          it so we can print it for debugging purposes.
      
      (2) All other, which used either default resources (ioport_resource and
          iomem_resource) or information read from the hardware via amd_bus.c or
          similar.  This used pci_scan_bus().
      
          This patch converts x86_pci_root_bus_res_quirks() (previously called
          from pcibios_fixup_bus()) to x86_pci_root_bus_resources(), which builds
          a list of resources before we call pci_scan_root_bus().
      
          We also use x86_pci_root_bus_resources() if we have ACPI but are
          ignoring _CRS.
      
      CC: Yinghai Lu <yinghai.lu@oracle.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      2cd6975a
    • M
      PCI: Pull PCI 'latency timer' setup up into the core · 96c55900
      Myron Stowe 提交于
      The 'latency timer' of PCI devices, both Type 0 and Type 1,
      is setup in architecture-specific code [see: 'pcibios_set_master()'].
      There are two approaches being taken by all the architectures - check
      if the 'latency timer' is currently set between 16 and 255 and if not
      bring it within bounds, or, do nothing (and then there is the
      gratuitously different PA-RISC implementation).
      
      There is nothing architecture-specific about PCI's 'latency timer' so
      this patch pulls its setup functionality up into the PCI core by
      creating a generic 'pcibios_set_master()' function using the '__weak'
      attribute which can be used by all architectures as a default which,
      if necessary, can then be over-ridden by architecture-specific code.
      
      No functional change.
      Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      96c55900
  12. 04 1月, 2012 2 次提交
    • E
      x86: Fix atomic64_xxx_cx8() functions · ceb7b40b
      Eric Dumazet 提交于
      It appears about all functions in arch/x86/lib/atomic64_cx8_32.S
      are wrong in case cmpxchg8b must be restarted, because
      LOCK_PREFIX macro defines a label "1" clashing with other local
      labels :
      
      1:
      	some_instructions
      	LOCK_PREFIX
      	cmpxchg8b (%ebp)
      	jne 1b  / jumps to beginning of LOCK_PREFIX !
      
      A possible fix is to use a magic label "672" in LOCK_PREFIX asm
      definition, similar to the "671" one we defined in
      LOCK_PREFIX_HERE.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Acked-by: NJan Beulich <JBeulich@suse.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1325608540.2320.103.camel@edumazet-HP-Compaq-6005-Pro-SFF-PCSigned-off-by: NIngo Molnar <mingo@elte.hu>
      ceb7b40b
    • J
      x86: Fix and improve cmpxchg_double{,_local}() · cdcd6298
      Jan Beulich 提交于
      Just like the per-CPU ones they had several
      problems/shortcomings:
      
      Only the first memory operand was mentioned in the asm()
      operands, and the 2x64-bit version didn't have a memory clobber
      while the 2x32-bit one did. The former allowed the compiler to
      not recognize the need to re-load the data in case it had it
      cached in some register, while the latter was overly
      destructive.
      
      The types of the local copies of the old and new values were
      incorrect (the types of the pointed-to variables should be used
      here, to make sure the respective old/new variable types are
      compatible).
      
      The __dummy/__junk variables were pointless, given that local
      copies of the inputs already existed (and can hence be used for
      discarded outputs).
      
      The 32-bit variant of cmpxchg_double_local() referenced
      cmpxchg16b_local().
      
      At once also:
      
       - change the return value type to what it really is: 'bool'
       - unify 32- and 64-bit variants
       - abstract out the common part of the 'normal' and 'local' variants
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/4F01F12A020000780006A19B@nat28.tlf.novell.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      cdcd6298
  13. 27 12月, 2011 12 次提交
  14. 24 12月, 2011 2 次提交
  15. 23 12月, 2011 1 次提交
  16. 22 12月, 2011 3 次提交
    • K
      cpu: convert 'cpu' and 'machinecheck' sysdev_class to a regular subsystem · 8a25a2fd
      Kay Sievers 提交于
      This moves the 'cpu sysdev_class' over to a regular 'cpu' subsystem
      and converts the devices to regular devices. The sysdev drivers are
      implemented as subsystem interfaces now.
      
      After all sysdev classes are ported to regular driver core entities, the
      sysdev implementation will be entirely removed from the kernel.
      
      Userspace relies on events and generic sysfs subsystem infrastructure
      from sysdev devices, which are made available with this conversion.
      
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Borislav Petkov <bp@amd64.org>
      Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8a25a2fd
    • S
      x86: Add counter when debug stack is used with interrupts enabled · 42181186
      Steven Rostedt 提交于
      Mathieu Desnoyers pointed out a case that can cause issues with
      NMIs running on the debug stack:
      
        int3 -> interrupt -> NMI -> int3
      
      Because the interrupt changes the stack, the NMI will not see that
      it preempted the debug stack. Looking deeper at this case,
      interrupts only happen when the int3 is from userspace or in
      an a location in the exception table (fixup).
      
        userspace -> int3 -> interurpt -> NMI -> int3
      
      All other int3s that happen in the kernel should be processed
      without ever enabling interrupts, as the do_trap() call will
      panic the kernel if it is called to process any other location
      within the kernel.
      
      Adding a counter around the sections that enable interrupts while
      using the debug stack allows the NMI to also check that case.
      If the NMI sees that it either interrupted a task using the debug
      stack or the debug counter is non-zero, then it will have to
      change the IDT table to make the int3 not change stacks (which will
      corrupt the stack if it does).
      
      Note, I had to move the debug_usage functions out of processor.h
      and into debugreg.h because of the static inlined functions to
      inc and dec the debug_usage counter. __get_cpu_var() requires
      smp.h which includes processor.h, and would fail to build.
      
      Link: http://lkml.kernel.org/r/1323976535.23971.112.camel@gandalf.stny.rr.comReported-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Paul Turner <pjt@google.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      42181186
    • S
      x86: Keep current stack in NMI breakpoints · 228bdaa9
      Steven Rostedt 提交于
      We want to allow NMI handlers to have breakpoints to be able to
      remove stop_machine from ftrace, kprobes and jump_labels. But if
      an NMI interrupts a current breakpoint, and then it triggers a
      breakpoint itself, it will switch to the breakpoint stack and
      corrupt the data on it for the breakpoint processing that it
      interrupted.
      
      Instead, have the NMI check if it interrupted breakpoint processing
      by checking if the stack that is currently used is a breakpoint
      stack. If it is, then load a special IDT that changes the IST
      for the debug exception to keep the same stack in kernel context.
      When the NMI is done, it puts it back.
      
      This way, if the NMI does trigger a breakpoint, it will keep
      using the same stack and not stomp on the breakpoint data for
      the breakpoint it interrupted.
      Suggested-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      228bdaa9
  17. 21 12月, 2011 1 次提交