1. 27 May, 2021 1 commit
  2. 10 May, 2021 1 commit
  3. 07 May, 2021 1 commit
  4. 26 Apr, 2021 1 commit
  5. 21 Apr, 2021 9 commits
  6. 20 Apr, 2021 3 commits
  7. 17 Apr, 2021 1 commit
  8. 09 Apr, 2021 1 commit
  9. 08 Apr, 2021 1 commit
  10. 07 Apr, 2021 2 commits
  11. 06 Apr, 2021 1 commit
  12. 24 Mar, 2021 1 commit
  13. 19 Mar, 2021 1 commit
  14. 18 Mar, 2021 1 commit
    • Sean Christopherson's avatar
      KVM: x86: Protect userspace MSR filter with SRCU, and set atomically-ish · b318e8de
      Sean Christopherson authored
      Fix a plethora of issues with MSR filtering by installing the resulting
      filter as an atomic bundle instead of updating the live filter one range
      at a time.  The KVM_X86_SET_MSR_FILTER ioctl() isn't truly atomic, as
      the hardware MSR bitmaps won't be updated until the next VM-Enter, but
      the relevant software struct is atomically updated, which is what KVM
      really needs.
      
      Similar to the approach used for modifying memslots, make arch.msr_filter
      a SRCU-protected pointer, do all the work configuring the new filter
      outside of kvm->lock, and then acquire kvm->lock only when the new filter
      has been vetted and created.  That way vCPU readers either see the old
      filter or the new filter in their entirety, not some half-baked state.
      
      Yuan Yao pointed out a use-after-free in ksm_msr_allowed() due to a
      TOCTOU bug, but that's just the tip of the iceberg...
      
        - Nothing is __rcu annotated, making it nigh impossible to audit the
          code for correctness.
        - kvm_add_msr_filter() has an unpaired smp_wmb().  Violation of kernel
          coding style aside, the lack of a smb_rmb() anywhere casts all code
          into doubt.
        - kvm_clear_msr_filter() has a double free TOCTOU bug, as it grabs
          count before taking the lock.
        - kvm_clear_msr_filter() also has memory leak due to the same TOCTOU bug.
      
      The entire approach of updating the live filter is also flawed.  While
      installing a new filter is inherently racy if vCPUs are running, fixing
      the above issues also makes it trivial to ensure certain behavior is
      deterministic, e.g. KVM can provide deterministic behavior for MSRs with
      identical settings in the old and new filters.  An atomic update of the
      filter also prevents KVM from getting into a half-baked state, e.g. if
      installing a filter fails, the existing approach would leave the filter
      in a half-baked state, having already committed whatever bits of the
      filter were already processed.
      
      [*] https://lkml.kernel.org/r/20210312083157.25403-1-yaoyuan0329os@gmail.com
      
      Fixes: 1a155254
      
       ("KVM: x86: Introduce MSR filtering")
      Cc: stable@vger.kernel.org
      Cc: Alexander Graf <graf@amazon.com>
      Reported-by: default avatarYuan Yao <yaoyuan0329os@gmail.com>
      Signed-off-by: default avatarSean Christopherson <seanjc@google.com>
      Message-Id: <20210316184436.2544875-2-seanjc@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      b318e8de
  15. 15 Mar, 2021 2 commits
  16. 12 Mar, 2021 1 commit
    • Marc Zyngier's avatar
      KVM: arm64: Reject VM creation when the default IPA size is unsupported · 7d717558
      Marc Zyngier authored
      KVM/arm64 has forever used a 40bit default IPA space, partially
      due to its 32bit heritage (where the only choice is 40bit).
      
      However, there are implementations in the wild that have a *cough*
      much smaller *cough* IPA space, which leads to a misprogramming of
      VTCR_EL2, and a guest that is stuck on its first memory access
      if userspace dares to ask for the default IPA setting (which most
      VMMs do).
      
      Instead, blundly reject the creation of such VM, as we can't
      satisfy the requirements from userspace (with a one-off warning).
      Also clarify the boot warning, and document that the VM creation
      will fail when an unsupported IPA size is provided.
      
      Although this is an ABI change, it doesn't really change much
      for userspace:
      
      - the guest couldn't run before this change, but no error was
        returned. At least userspace knows what is happening.
      
      - a memory slot that was accepted because it did fit the default
        IPA space now doesn't even get a chance to be registered.
      
      The other thing that is left doing is to convince userspace to
      actually use the IPA space setting instead of relying on the
      antiquated default.
      
      Fixes: 233a7cb2
      
       ("kvm: arm64: Allow tuning the physical address size for VM")
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Cc: stable@vger.kernel.org
      Reviewed-by: Andrew Jones's avatarAndrew Jones <drjones@redhat.com>
      Reviewed-by: default avatarEric Auger <eric.auger@redhat.com>
      Link: https://lore.kernel.org/r/20210311100016.3830038-2-maz@kernel.org
      7d717558
  17. 09 Mar, 2021 2 commits
  18. 02 Mar, 2021 2 commits
    • David Woodhouse's avatar
      KVM: x86/xen: Add support for vCPU runstate information · 30b5c851
      David Woodhouse authored
      
      
      This is how Xen guests do steal time accounting. The hypervisor records
      the amount of time spent in each of running/runnable/blocked/offline
      states.
      
      In the Xen accounting, a vCPU is still in state RUNSTATE_running while
      in Xen for a hypercall or I/O trap, etc. Only if Xen explicitly schedules
      does the state become RUNSTATE_blocked. In KVM this means that even when
      the vCPU exits the kvm_run loop, the state remains RUNSTATE_running.
      
      The VMM can explicitly set the vCPU to RUNSTATE_blocked by using the
      KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_CURRENT attribute, and can also use
      KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST to retrospectively add a given
      amount of time to the blocked state and subtract it from the running
      state.
      
      The state_entry_time corresponds to get_kvmclock_ns() at the time the
      vCPU entered the current state, and the total times of all four states
      should always add up to state_entry_time.
      
      Co-developed-by: default avatarJoao Martins <joao.m.martins@oracle.com>
      Signed-off-by: default avatarJoao Martins <joao.m.martins@oracle.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Message-Id: <20210301125309.874953-2-dwmw2@infradead.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      30b5c851
    • Kai Huang's avatar
      KVM: Documentation: Fix index for KVM_CAP_PPC_DAWR1 · 7d2cdad0
      Kai Huang authored
      
      
      It should be 7.23 instead of 7.22, which has already been taken by
      KVM_CAP_X86_BUS_LOCK_EXIT.
      
      Signed-off-by: default avatarKai Huang <kai.huang@intel.com>
      Message-Id: <20210226094832.380394-1-kai.huang@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      7d2cdad0
  19. 26 Feb, 2021 2 commits
  20. 22 Feb, 2021 1 commit
    • Lukas Bulwahn's avatar
      KVM: Documentation: rectify rst markup in KVM_GET_SUPPORTED_HV_CPUID · 356c7558
      Lukas Bulwahn authored
      Commit c21d54f0
      
       ("KVM: x86: hyper-v: allow KVM_GET_SUPPORTED_HV_CPUID
      as a system ioctl") added an enumeration in the KVM_GET_SUPPORTED_HV_CPUID
      documentation improperly for rst, and caused new warnings in make htmldocs:
      
        Documentation/virt/kvm/api.rst:4536: WARNING: Unexpected indentation.
        Documentation/virt/kvm/api.rst:4538: WARNING: Block quote ends without a blank line; unexpected unindent.
      
      Fix that issue and another historic rst markup issue from the initial
      rst conversion in the KVM_GET_SUPPORTED_HV_CPUID documentation.
      
      Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      Message-Id: <20210104095938.24838-1-lukas.bulwahn@gmail.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      356c7558
  21. 10 Feb, 2021 2 commits
  22. 09 Feb, 2021 3 commits