1. 26 5月, 2018 8 次提交
  2. 25 5月, 2018 6 次提交
  3. 23 5月, 2018 4 次提交
    • J
      KVM: nVMX: Ensure that VMCS12 field offsets do not change · 21ebf53b
      Jim Mattson 提交于
      Enforce the invariant that existing VMCS12 field offsets must not
      change. Experience has shown that without strict enforcement, this
      invariant will not be maintained.
      Signed-off-by: NJim Mattson <jmattson@google.com>
      Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      [Changed the code to use BUILD_BUG_ON_MSG instead of better, but GCC 4.6
       requiring _Static_assert. - Radim.]
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      21ebf53b
    • J
      KVM: nVMX: Restore the VMCS12 offsets for v4.0 fields · b348e793
      Jim Mattson 提交于
      Changing the VMCS12 layout will break save/restore compatibility with
      older kvm releases once the KVM_{GET,SET}_NESTED_STATE ioctls are
      accepted upstream. Google has already been using these ioctls for some
      time, and we implore the community not to disturb the existing layout.
      
      Move the four most recently added fields to preserve the offsets of
      the previously defined fields and reserve locations for the vmread and
      vmwrite bitmaps, which will be used in the virtualization of VMCS
      shadowing (to improve the performance of double-nesting).
      Signed-off-by: NJim Mattson <jmattson@google.com>
      Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      [Kept the SDM order in vmcs_field_to_offset_table. - Radim]
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      b348e793
    • A
      KVM: x86: use timespec64 for KVM_HC_CLOCK_PAIRING · 899a31f5
      Arnd Bergmann 提交于
      The hypercall was added using a struct timespec based implementation,
      but we should not use timespec in new code.
      
      This changes it to timespec64. There is no functional change
      here since the implementation is only used in 64-bit kernels
      that use the same definition for timespec and timespec64.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      899a31f5
    • J
      kvm: nVMX: Use nested_run_pending rather than from_vmentry · 6514dc38
      Jim Mattson 提交于
      When saving a vCPU's nested state, the vmcs02 is discarded. Only the
      shadow vmcs12 is saved. The shadow vmcs12 contains all of the
      information needed to reconstruct an equivalent vmcs02 on restore, but
      we have to be able to deal with two contexts:
      
      1. The nested state was saved immediately after an emulated VM-entry,
         before the vmcs02 was ever launched.
      
      2. The nested state was saved some time after the first successful
         launch of the vmcs02.
      
      Though it's an implementation detail rather than an architected bit,
      vmx->nested_run_pending serves to distinguish between these two
      cases. Hence, we save it as part of the vCPU's nested state. (Yes,
      this is ugly.)
      
      Even when restoring from a checkpoint, it may be necessary to build
      the vmcs02 as if prepare_vmcs02 was called from nested_vmx_run. So,
      the 'from_vmentry' argument should be dropped, and
      vmx->nested_run_pending should be consulted instead. The nested state
      restoration code then has to set vmx->nested_run_pending prior to
      calling prepare_vmcs02. It's important that the restoration code set
      vmx->nested_run_pending anyway, since the flag impacts things like
      interrupt delivery as well.
      
      Fixes: cf8b84f4 ("kvm: nVMX: Prepare for checkpointing L2 state")
      Signed-off-by: NJim Mattson <jmattson@google.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      6514dc38
  4. 20 5月, 2018 1 次提交
    • T
      x86/Hyper-V/hv_apic: Build the Hyper-V APIC conditionally · 2d2ccf24
      Thomas Gleixner 提交于
      The Hyper-V APIC code is built when CONFIG_HYPERV is enabled but the actual
      code in that file is guarded with CONFIG_X86_64. There is no point in doing
      this. Neither is there a point in having the CONFIG_HYPERV guard in there
      because the containing directory is not built when CONFIG_HYPERV=n.
      
      Further for the hv_init_apic() function a stub is provided only for
      CONFIG_HYPERV=n, which is pointless as the callsite is not compiled at
      all. But for X86_32 the stub is missing and the build fails.
      
      Clean that up:
      
        - Compile hv_apic.c only when CONFIG_X86_64=y
        - Make the stub for hv_init_apic() available when CONFG_X86_64=n
      
      Fixes: 6b48cb5f ("X86/Hyper-V: Enlighten APIC access")
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Michael Kelley <mikelley@microsoft.com>
      2d2ccf24
  5. 19 5月, 2018 21 次提交