1. 22 10月, 2021 3 次提交
    • D
      KVM: x86/mmu: Rename slot_handle_leaf to slot_handle_level_4k · 610265ea
      David Matlack 提交于
      slot_handle_leaf is a misnomer because it only operates on 4K SPTEs
      whereas "leaf" is used to describe any valid terminal SPTE (4K or
      large page). Rename slot_handle_leaf to slot_handle_level_4k to
      avoid confusion.
      
      Making this change makes it more obvious there is a benign discrepency
      between the legacy MMU and the TDP MMU when it comes to dirty logging.
      The legacy MMU only iterates through 4K SPTEs when zapping for
      collapsing and when clearing D-bits. The TDP MMU, on the other hand,
      iterates through SPTEs on all levels.
      
      The TDP MMU behavior of zapping SPTEs at all levels is technically
      overkill for its current dirty logging implementation, which always
      demotes to 4k SPTES, but both the TDP MMU and legacy MMU zap if and only
      if the SPTE can be replaced by a larger page, i.e. will not spuriously
      zap 2m (or larger) SPTEs. Opportunistically add comments to explain this
      discrepency in the code.
      Signed-off-by: NDavid Matlack <dmatlack@google.com>
      Message-Id: <20211019162223.3935109-1-dmatlack@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      610265ea
    • P
      KVM: x86/mmu: clean up prefetch/prefault/speculative naming · 2839180c
      Paolo Bonzini 提交于
      "prefetch", "prefault" and "speculative" are used throughout KVM to mean
      the same thing.  Use a single name, standardizing on "prefetch" which
      is already used by various functions such as direct_pte_prefetch,
      FNAME(prefetch_gpte), FNAME(pte_prefetch), etc.
      Suggested-by: NDavid Matlack <dmatlack@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      2839180c
    • D
      KVM: cleanup allocation of rmaps and page tracking data · 1e76a3ce
      David Stevens 提交于
      Unify the flags for rmaps and page tracking data, using a
      single flag in struct kvm_arch and a single loop to go
      over all the address spaces and memslots.  This avoids
      code duplication between alloc_all_memslots_rmaps and
      kvm_page_track_enable_mmu_write_tracking.
      Signed-off-by: NDavid Stevens <stevensd@chromium.org>
      [This patch is the delta between David's v2 and v3, with conflicts
       fixed and my own commit message. - Paolo]
      Co-developed-by: NSean Christopherson <seanjc@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      1e76a3ce
  2. 18 10月, 2021 1 次提交
  3. 01 10月, 2021 27 次提交
  4. 30 9月, 2021 6 次提交
  5. 23 9月, 2021 1 次提交
  6. 06 9月, 2021 2 次提交
    • P
      KVM: MMU: mark role_regs and role accessors as maybe unused · 4ac21457
      Paolo Bonzini 提交于
      It is reasonable for these functions to be used only in some configurations,
      for example only if the host is 64-bits (and therefore supports 64-bit
      guests).  It is also reasonable to keep the role_regs and role accessors
      in sync even though some of the accessors may be used only for one of the
      two sets (as is the case currently for CR4.LA57)..
      
      Because clang reports warnings for unused inlines declared in a .c file,
      mark both sets of accessors as __maybe_unused.
      Reported-by: Nkernel test robot <lkp@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      4ac21457
    • S
      Revert "KVM: x86: mmu: Add guest physical address check in translate_gpa()" · e7177339
      Sean Christopherson 提交于
      Revert a misguided illegal GPA check when "translating" a non-nested GPA.
      The check is woefully incomplete as it does not fill in @exception as
      expected by all callers, which leads to KVM attempting to inject a bogus
      exception, potentially exposing kernel stack information in the process.
      
       WARNING: CPU: 0 PID: 8469 at arch/x86/kvm/x86.c:525 exception_type+0x98/0xb0 arch/x86/kvm/x86.c:525
       CPU: 1 PID: 8469 Comm: syz-executor531 Not tainted 5.14.0-rc7-syzkaller #0
       RIP: 0010:exception_type+0x98/0xb0 arch/x86/kvm/x86.c:525
       Call Trace:
        x86_emulate_instruction+0xef6/0x1460 arch/x86/kvm/x86.c:7853
        kvm_mmu_page_fault+0x2f0/0x1810 arch/x86/kvm/mmu/mmu.c:5199
        handle_ept_misconfig+0xdf/0x3e0 arch/x86/kvm/vmx/vmx.c:5336
        __vmx_handle_exit arch/x86/kvm/vmx/vmx.c:6021 [inline]
        vmx_handle_exit+0x336/0x1800 arch/x86/kvm/vmx/vmx.c:6038
        vcpu_enter_guest+0x2a1c/0x4430 arch/x86/kvm/x86.c:9712
        vcpu_run arch/x86/kvm/x86.c:9779 [inline]
        kvm_arch_vcpu_ioctl_run+0x47d/0x1b20 arch/x86/kvm/x86.c:10010
        kvm_vcpu_ioctl+0x49e/0xe50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3652
      
      The bug has escaped notice because practically speaking the GPA check is
      useless.  The GPA check in question only comes into play when KVM is
      walking guest page tables (or "translating" CR3), and KVM already handles
      illegal GPA checks by setting reserved bits in rsvd_bits_mask for each
      PxE, or in the case of CR3 for loading PTDPTRs, manually checks for an
      illegal CR3.  This particular failure doesn't hit the existing reserved
      bits checks because syzbot sets guest.MAXPHYADDR=1, and IA32 architecture
      simply doesn't allow for such an absurd MAXPHYADDR, e.g. 32-bit paging
      doesn't define any reserved PA bits checks, which KVM emulates by only
      incorporating the reserved PA bits into the "high" bits, i.e. bits 63:32.
      
      Simply remove the bogus check.  There is zero meaningful value and no
      architectural justification for supporting guest.MAXPHYADDR < 32, and
      properly filling the exception would introduce non-trivial complexity.
      
      This reverts commit ec7771ab.
      
      Fixes: ec7771ab ("KVM: x86: mmu: Add guest physical address check in translate_gpa()")
      Cc: stable@vger.kernel.org
      Reported-by: syzbot+200c08e88ae818f849ce@syzkaller.appspotmail.com
      Signed-off-by: NSean Christopherson <seanjc@google.com>
      Message-Id: <20210831164224.1119728-2-seanjc@google.com>
      Reviewed-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      e7177339