1. 18 12月, 2014 1 次提交
  2. 05 12月, 2014 1 次提交
  3. 12 11月, 2014 2 次提交
  4. 24 10月, 2014 1 次提交
  5. 21 8月, 2014 1 次提交
  6. 16 8月, 2014 1 次提交
  7. 21 7月, 2014 1 次提交
  8. 17 7月, 2014 1 次提交
  9. 19 6月, 2014 1 次提交
  10. 30 5月, 2014 1 次提交
    • F
      x86/xsaves: Detect xsaves/xrstors feature · 6229ad27
      Fenghua Yu 提交于
      Detect the xsaveopt, xsavec, xgetbv, and xsaves features in processor extended
      state enumberation sub-leaf (eax=0x0d, ecx=1):
      Bit 00: XSAVEOPT is available
      Bit 01: Supports XSAVEC and the compacted form of XRSTOR if set
      Bit 02: Supports XGETBV with ECX = 1 if set
      Bit 03: Supports XSAVES/XRSTORS and IA32_XSS if set
      
      The above features are defined in the new word 10 in cpu features.
      
      The IA32_XSS MSR (index DA0H) contains a state-component bitmap that specifies
      the state components that software has enabled xsaves and xrstors to manage.
      If the bit corresponding to a state component is clear in XCR0 | IA32_XSS,
      xsaves and xrstors will not operate on that state component, regardless of
      the value of the instruction mask.
      Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
      Link: http://lkml.kernel.org/r/1401387164-43416-3-git-send-email-fenghua.yu@intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      6229ad27
  11. 09 5月, 2014 1 次提交
  12. 06 5月, 2014 1 次提交
  13. 14 3月, 2014 2 次提交
  14. 24 2月, 2014 1 次提交
  15. 21 1月, 2014 1 次提交
  16. 17 1月, 2014 2 次提交
    • J
      KVM: nVMX: Clean up handling of VMX-related MSRs · cae50139
      Jan Kiszka 提交于
      This simplifies the code and also stops issuing warning about writing to
      unhandled MSRs when VMX is disabled or the Feature Control MSR is
      locked - we do handle them all according to the spec.
      Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      cae50139
    • V
      add support for Hyper-V reference time counter · e984097b
      Vadim Rozenfeld 提交于
      Signed-off: Peter Lieven <pl@kamp.de>
      Signed-off: Gleb Natapov
      Signed-off: Vadim Rozenfeld <vrozenfe@redhat.com>
      
      After some consideration I decided to submit only Hyper-V reference
      counters support this time. I will submit iTSC support as a separate
      patch as soon as it is ready.
      
      v1 -> v2
      1. mark TSC page dirty as suggested by
          Eric Northup <digitaleric@google.com> and Gleb
      2. disable local irq when calling get_kernel_ns,
          as it was done by Peter Lieven <pl@amp.de>
      3. move check for TSC page enable from second patch
          to this one.
      
      v3 -> v4
          Get rid of ref counter offset.
      
      v4 -> v5
          replace __copy_to_user with kvm_write_guest
          when updateing iTSC page.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      e984097b
  17. 15 1月, 2014 1 次提交
  18. 29 12月, 2013 2 次提交
    • D
      x86: Add xloadflags bit for EFI runtime support on kexec · 456a29dd
      Dave Young 提交于
      Old kexec-tools can not load new kernels. The reason is kexec-tools does
      not fill efi_info in x86 setup header previously, thus EFI failed to
      initialize.  In new kexec-tools it will by default to fill efi_info and
      pass other EFI required infomation to 2nd kernel so kexec kernel EFI
      initialization can succeed finally.
      
      To prevent from breaking userspace, add a new xloadflags bit so
      kexec-tools can check the flag and switch to old logic.
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Acked-by: NBorislav Petkov <bp@suse.de>
      Tested-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      456a29dd
    • D
      x86/efi: Pass necessary EFI data for kexec via setup_data · 1fec0533
      Dave Young 提交于
      Add a new setup_data type SETUP_EFI for kexec use.  Passing the saved
      fw_vendor, runtime, config tables and EFI runtime mappings.
      
      When entering virtual mode, directly mapping the EFI runtime regions
      which we passed in previously. And skip the step to call
      SetVirtualAddressMap().
      
      Specially for HP z420 workstation we need save the smbios physical
      address.  The kernel boot sequence proceeds in the following order.
      Step 2 requires efi.smbios to be the physical address.  However, I found
      that on HP z420 EFI system table has a virtual address of SMBIOS in step
      1.  Hence, we need set it back to the physical address with the smbios
      in efi_setup_data.  (When it is still the physical address, it simply
      sets the same value.)
      
      1. efi_init() - Set efi.smbios from EFI system table
      2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
      3. efi_enter_virtual_mode() - Map EFI ranges
      
      Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
      HP z420 workstation.
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Tested-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      1fec0533
  19. 21 12月, 2013 1 次提交
  20. 13 11月, 2013 1 次提交
    • L
      tools / power turbostat: Support Silvermont · 144b44b1
      Len Brown 提交于
      Support the next generation Intel Atom processor
      mirco-architecture, formerly called Silvermont.
      
      The server version, formerly called "Avoton",
      is named the "Intel(R) Atom(TM) Processor C2000 Product Family".
      
      The client version, formerly called "Bay Trail",
      is named the "Intel Atom Processor Z3000 Series",
      as well as various "Intel Pentium Processor"
      and "Intel Celeron Processor" brands, depending
      on form-factor.
      
      Silvermont has a set of MSRs not far off from NHM,
      but the RAPL register set is a sub-set of those previously supported.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      144b44b1
  21. 31 10月, 2013 1 次提交
    • B
      kvm: Add KVM_GET_EMULATED_CPUID · 9c15bb1d
      Borislav Petkov 提交于
      Add a kvm ioctl which states which system functionality kvm emulates.
      The format used is that of CPUID and we return the corresponding CPUID
      bits set for which we do emulate functionality.
      
      Make sure ->padding is being passed on clean from userspace so that we
      can use it for something in the future, after the ioctl gets cast in
      stone.
      
      s/kvm_dev_ioctl_get_supported_cpuid/kvm_dev_ioctl_get_cpuid/ while at
      it.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      9c15bb1d
  22. 18 10月, 2013 1 次提交
  23. 11 10月, 2013 2 次提交
  24. 26 8月, 2013 1 次提交
  25. 13 8月, 2013 1 次提交
  26. 09 8月, 2013 1 次提交
  27. 07 8月, 2013 1 次提交
  28. 26 6月, 2013 4 次提交
  29. 11 6月, 2013 1 次提交
    • M
      Modify UEFI anti-bricking code · f8b84043
      Matthew Garrett 提交于
      This patch reworks the UEFI anti-bricking code, including an effective
      reversion of cc5a080c and 31ff2f20. It turns out that calling
      QueryVariableInfo() from boot services results in some firmware
      implementations jumping to physical addresses even after entering virtual
      mode, so until we have 1:1 mappings for UEFI runtime space this isn't
      going to work so well.
      
      Reverting these gets us back to the situation where we'd refuse to create
      variables on some systems because they classify deleted variables as "used"
      until the firmware triggers a garbage collection run, which they won't do
      until they reach a lower threshold. This results in it being impossible to
      install a bootloader, which is unhelpful.
      
      Feedback from Samsung indicates that the firmware doesn't need more than
      5KB of storage space for its own purposes, so that seems like a reasonable
      threshold. However, there's still no guarantee that a platform will attempt
      garbage collection merely because it drops below this threshold. It seems
      that this is often only triggered if an attempt to write generates a
      genuine EFI_OUT_OF_RESOURCES error. We can force that by attempting to
      create a variable larger than the remaining space. This should fail, but if
      it somehow succeeds we can then immediately delete it.
      
      I've tested this on the UEFI machines I have available, but I don't have
      a Samsung and so can't verify that it avoids the bricking problem.
      Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: Lee, Chun-Y <jlee@suse.com> [ dummy variable cleanup ]
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      f8b84043
  30. 28 4月, 2013 1 次提交
  31. 22 4月, 2013 1 次提交
  32. 21 4月, 2013 1 次提交