1. 01 4月, 2016 1 次提交
  2. 22 3月, 2016 3 次提交
  3. 10 3月, 2016 1 次提交
    • P
      KVM: MMU: fix reserved bit check for ept=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 · 5f0b8199
      Paolo Bonzini 提交于
      KVM has special logic to handle pages with pte.u=1 and pte.w=0 when
      CR0.WP=1.  These pages' SPTEs flip continuously between two states:
      U=1/W=0 (user and supervisor reads allowed, supervisor writes not allowed)
      and U=0/W=1 (supervisor reads and writes allowed, user writes not allowed).
      
      When SMEP is in effect, however, U=0 will enable kernel execution of
      this page.  To avoid this, KVM also sets NX=1 in the shadow PTE together
      with U=0, making the two states U=1/W=0/NX=gpte.NX and U=0/W=1/NX=1.
      When guest EFER has the NX bit cleared, the reserved bit check thinks
      that the latter state is invalid; teach it that the smep_andnot_wp case
      will also use the NX bit of SPTEs.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: NXiao Guangrong <guangrong.xiao@linux.inel.com>
      Fixes: c258b62bSigned-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      5f0b8199
  4. 08 3月, 2016 8 次提交
  5. 04 3月, 2016 3 次提交
    • X
      KVM: MMU: check kvm_mmu_pages and mmu_page_path indices · e23d3fef
      Xiao Guangrong 提交于
      Give a special invalid index to the root of the walk, so that we
      can check the consistency of kvm_mmu_pages and mmu_page_path.
      Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
      [Extracted from a bigger patch proposed by Guangrong. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      e23d3fef
    • P
      KVM: MMU: Fix ubsan warnings · 0a47cd85
      Paolo Bonzini 提交于
      kvm_mmu_pages_init is doing some really yucky stuff.  It is setting
      up a sentinel for mmu_page_clear_parents; however, because of a) the
      way levels are numbered starting from 1 and b) the way mmu_page_path
      sizes its arrays with PT64_ROOT_LEVEL-1 elements, the access can be
      out of bounds.  This is harmless because the code overwrites up to the
      first two elements of parents->idx and these are initialized, and
      because the sentinel is not needed in this case---mmu_page_clear_parents
      exits anyway when it gets to the end of the array.  However ubsan
      complains, and everyone else should too.
      
      This fix does three things.  First it makes the mmu_page_path arrays
      PT64_ROOT_LEVEL elements in size, so that we can write to them without
      checking the level in advance.  Second it disintegrates kvm_mmu_pages_init
      between mmu_unsync_walk (to reset the struct kvm_mmu_pages) and
      for_each_sp (to place the NULL sentinel at the end of the current path).
      This is okay because the mmu_page_path is only used in
      mmu_pages_clear_parents; mmu_pages_clear_parents itself is called within
      a for_each_sp iterator, and hence always after a call to mmu_pages_next.
      Third it changes mmu_pages_clear_parents to just use the sentinel to
      stop iteration, without checking the bounds on level.
      Reported-by: NSasha Levin <sasha.levin@oracle.com>
      Reported-by: NMike Krinkin <krinkin.m.u@gmail.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      0a47cd85
    • P
      KVM: MMU: cleanup handle_abnormal_pfn · 798e88b3
      Paolo Bonzini 提交于
      The goto and temporary variable are unnecessary, just use return
      statements.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      798e88b3
  6. 03 3月, 2016 8 次提交
  7. 24 2月, 2016 1 次提交
  8. 23 2月, 2016 3 次提交
  9. 16 1月, 2016 1 次提交
    • D
      kvm: rename pfn_t to kvm_pfn_t · ba049e93
      Dan Williams 提交于
      To date, we have implemented two I/O usage models for persistent memory,
      PMEM (a persistent "ram disk") and DAX (mmap persistent memory into
      userspace).  This series adds a third, DAX-GUP, that allows DAX mappings
      to be the target of direct-i/o.  It allows userspace to coordinate
      DMA/RDMA from/to persistent memory.
      
      The implementation leverages the ZONE_DEVICE mm-zone that went into
      4.3-rc1 (also discussed at kernel summit) to flag pages that are owned
      and dynamically mapped by a device driver.  The pmem driver, after
      mapping a persistent memory range into the system memmap via
      devm_memremap_pages(), arranges for DAX to distinguish pfn-only versus
      page-backed pmem-pfns via flags in the new pfn_t type.
      
      The DAX code, upon seeing a PFN_DEV+PFN_MAP flagged pfn, flags the
      resulting pte(s) inserted into the process page tables with a new
      _PAGE_DEVMAP flag.  Later, when get_user_pages() is walking ptes it keys
      off _PAGE_DEVMAP to pin the device hosting the page range active.
      Finally, get_page() and put_page() are modified to take references
      against the device driver established page mapping.
      
      Finally, this need for "struct page" for persistent memory requires
      memory capacity to store the memmap array.  Given the memmap array for a
      large pool of persistent may exhaust available DRAM introduce a
      mechanism to allocate the memmap from persistent memory.  The new
      "struct vmem_altmap *" parameter to devm_memremap_pages() enables
      arch_add_memory() to use reserved pmem capacity rather than the page
      allocator.
      
      This patch (of 18):
      
      The core has developed a need for a "pfn_t" type [1].  Move the existing
      pfn_t in KVM to kvm_pfn_t [2].
      
      [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-September/002199.html
      [2]: https://lists.01.org/pipermail/linux-nvdimm/2015-September/002218.htmlSigned-off-by: NDan Williams <dan.j.williams@intel.com>
      Acked-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ba049e93
  10. 07 1月, 2016 1 次提交
  11. 19 12月, 2015 1 次提交
  12. 26 11月, 2015 9 次提交