All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

  1. 15 Jan, 2016 1 commit
    • Dan Williams's avatar
      kvm: rename pfn_t to kvm_pfn_t · ba049e93
      Dan Williams authored
      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
      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].
      [2]: default avatarDan Williams <>
      Acked-by: default avatarChristoffer Dall <>
      Cc: Paolo Bonzini <>
      Signed-off-by: default avatarAndrew Morton <>
      Signed-off-by: default avatarLinus Torvalds <>
  2. 26 May, 2015 1 commit
  3. 18 Dec, 2014 1 commit
  4. 29 Aug, 2014 1 commit
  5. 07 Apr, 2013 1 commit
  6. 12 Jan, 2011 1 commit
  7. 01 Aug, 2010 1 commit
  8. 10 Jun, 2009 2 commits
  9. 24 Mar, 2009 2 commits
  10. 27 Apr, 2008 1 commit
    • Anthony Liguori's avatar
      KVM: MMU: Don't assume struct page for x86 · 35149e21
      Anthony Liguori authored
      This patch introduces a gfn_to_pfn() function and corresponding functions like
      kvm_release_pfn_dirty().  Using these new functions, we can modify the x86
      MMU to no longer assume that it can always get a struct page for any given gfn.
      We don't want to eliminate gfn_to_page() entirely because a number of places
      assume they can do gfn_to_page() and then kmap() the results.  When we support
      IO memory, gfn_to_page() will fail for IO pages although gfn_to_pfn() will
      This does not implement support for avoiding reference counting for reserved
      RAM or for IO memory.  However, it should make those things pretty straight
      Since we're only introducing new common symbols, I don't think it will break
      the non-x86 architectures but I haven't tested those.  I've tested Intel,
      AMD, NPT, and hugetlbfs with Windows and Linux guests.
      [avi: fix overflow when shifting left pfns by adding casts]
      Signed-off-by: default avatarAnthony Liguori <>
      Signed-off-by: default avatarAvi Kivity <>
  11. 30 Jan, 2008 3 commits
  12. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!