1. 23 2月, 2016 1 次提交
  2. 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
  3. 26 11月, 2015 4 次提交
  4. 10 11月, 2015 1 次提交
  5. 19 10月, 2015 1 次提交
    • T
      KVM: x86: MMU: Initialize force_pt_level before calling mapping_level() · 8c85ac1c
      Takuya Yoshikawa 提交于
      Commit fd136902 ("KVM: x86: MMU: Move mapping_level_dirty_bitmap()
      call in mapping_level()") forgot to initialize force_pt_level to false
      in FNAME(page_fault)() before calling mapping_level() like
      nonpaging_map() does.  This can sometimes result in forcing page table
      level mapping unnecessarily.
      
      Fix this and move the first *force_pt_level check in mapping_level()
      before kvm_vcpu_gfn_to_memslot() call to make it a bit clearer that
      the variable must be initialized before mapping_level() gets called.
      
      This change can also avoid calling kvm_vcpu_gfn_to_memslot() when
      !check_hugepage_cache_consistency() check in tdp_page_fault() forces
      page table level mapping.
      Signed-off-by: NTakuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      8c85ac1c
  6. 16 10月, 2015 3 次提交
  7. 05 8月, 2015 1 次提交
  8. 05 6月, 2015 1 次提交
  9. 11 5月, 2015 1 次提交
  10. 08 5月, 2015 1 次提交
  11. 24 10月, 2014 1 次提交
  12. 24 9月, 2014 1 次提交
  13. 05 9月, 2014 1 次提交
  14. 03 9月, 2014 1 次提交
  15. 24 4月, 2014 1 次提交
  16. 15 4月, 2014 1 次提交
  17. 18 2月, 2014 1 次提交
  18. 15 1月, 2014 1 次提交
  19. 17 9月, 2013 1 次提交
  20. 07 8月, 2013 7 次提交
  21. 27 6月, 2013 2 次提交
  22. 07 4月, 2013 1 次提交
  23. 22 3月, 2013 1 次提交
    • T
      KVM: MMU: Move kvm_mmu_free_some_pages() into kvm_mmu_alloc_page() · 7ddca7e4
      Takuya Yoshikawa 提交于
      What this function is doing is to ensure that the number of shadow pages
      does not exceed the maximum limit stored in n_max_mmu_pages: so this is
      placed at every code path that can reach kvm_mmu_alloc_page().
      
      Although it might have some sense to spread this function in each such
      code path when it could be called before taking mmu_lock, the rule was
      changed not to do so.
      
      Taking this background into account, this patch moves it into
      kvm_mmu_alloc_page() and simplifies the code.
      
      Note: the unlikely hint in kvm_mmu_free_some_pages() guarantees that the
      overhead of this function is almost zero except when we actually need to
      allocate some shadow pages, so we do not need to care about calling it
      multiple times in one path by doing kvm_mmu_get_page() a few times.
      Signed-off-by: NTakuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      7ddca7e4
  24. 07 2月, 2013 1 次提交
  25. 05 2月, 2013 1 次提交
  26. 22 1月, 2013 1 次提交
  27. 11 1月, 2013 2 次提交
    • X
      KVM: MMU: fix infinite fault access retry · 7751babd
      Xiao Guangrong 提交于
      We have two issues in current code:
      - if target gfn is used as its page table, guest will refault then kvm will use
        small page size to map it. We need two #PF to fix its shadow page table
      
      - sometimes, say a exception is triggered during vm-exit caused by #PF
        (see handle_exception() in vmx.c), we remove all the shadow pages shadowed
        by the target gfn before go into page fault path, it will cause infinite
        loop:
        delete shadow pages shadowed by the gfn -> try to use large page size to map
        the gfn -> retry the access ->...
      
      To fix these, we can adjust page size early if the target gfn is used as page
      table
      Signed-off-by: NXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      7751babd
    • X
      KVM: MMU: fix Dirty bit missed if CR0.WP = 0 · c2288505
      Xiao Guangrong 提交于
      If the write-fault access is from supervisor and CR0.WP is not set on the
      vcpu, kvm will fix it by adjusting pte access - it sets the W bit on pte
      and clears U bit. This is the chance that kvm can change pte access from
      readonly to writable
      
      Unfortunately, the pte access is the access of 'direct' shadow page table,
      means direct sp.role.access = pte_access, then we will create a writable
      spte entry on the readonly shadow page table. It will cause Dirty bit is
      not tracked when two guest ptes point to the same large page. Note, it
      does not have other impact except Dirty bit since cr0.wp is encoded into
      sp.role
      
      It can be fixed by adjusting pte access before establishing shadow page
      table. Also, after that, no mmu specified code exists in the common function
      and drop two parameters in set_spte
      Signed-off-by: NXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      c2288505