1. 18 Jun, 2019 7 commits
    • Thomas Hellstrom's avatar
      drm/vmwgfx: Implement an infrastructure for write-coherent resources · 93392217
      Thomas Hellstrom authored
      This infrastructure will, for coherent resources, make sure that
      from the user-space point of view, data written by the CPU is immediately
      automatically available to the GPU at resource validation time.
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: default avatarDeepak Rawat <drawat@vmware.com>
      93392217
    • Thomas Hellstrom's avatar
      drm/ttm: TTM fault handler helpers · 7a39f35c
      Thomas Hellstrom authored
      With the vmwgfx dirty tracking, the default TTM fault handler is not
      completely sufficient (vmwgfx need to modify the vma->vm_flags member,
      and also needs to restrict the number of prefaults).
      
      We also want to replicate the new ttm_bo_vm_reserve() functionality
      
      So start turning the TTM vm code into helpers: ttm_bo_vm_fault_reserved()
      and ttm_bo_vm_reserve(), and provide a default TTM fault handler for other
      drivers to use.
      
      Cc: "Christian König" <christian.koenig@amd.com>
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: "Christian König" <christian.koenig@amd.com> #v1
      7a39f35c
    • Thomas Hellstrom's avatar
      drm/ttm: Allow the driver to provide the ttm struct vm_operations_struct · 32d1f698
      Thomas Hellstrom authored
      Add a pointer to the struct vm_operations_struct in the bo_device, and
      assign that pointer to the default value currently used.
      
      The driver can then optionally modify that pointer and the new value
      can be used for each new vma created.
      
      Cc: "Christian König" <christian.koenig@amd.com>
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      32d1f698
    • Thomas Hellstrom's avatar
      mm: Add write-protect and clean utilities for address space ranges · 4fe51e9e
      Thomas Hellstrom authored
      Add two utilities to a) write-protect and b) clean all ptes pointing into
      a range of an address space.
      The utilities are intended to aid in tracking dirty pages (either
      driver-allocated system memory or pci device memory).
      The write-protect utility should be used in conjunction with
      page_mkwrite() and pfn_mkwrite() to trigger write page-faults on page
      accesses. Typically one would want to use this on sparse accesses into
      large memory regions. The clean utility should be used to utilize
      hardware dirtying functionality and avoid the overhead of page-faults,
      typically on large accesses into small memory regions.
      
      The added file "as_dirty_helpers.c" is initially listed as maintained by
      VMware under our DRM driver. If somebody would like it elsewhere,
      that's of course no problem.
      
      Notable changes since RFC:
      - Added comments to help avoid the usage of these function for VMAs
        it's not intended for. We also do advisory checks on the vm_flags and
        warn on illegal usage.
      - Perform the pte modifications the same way softdirty does.
      - Add mmu_notifier range invalidation calls.
      - Add a config option so that this code is not unconditionally included.
      - Tell the mmu_gather code about pending tlb flushes.
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rik van Riel <riel@surriel.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Souptick Joarder <jrdr.linux@gmail.com>
      Cc: "Jérôme Glisse" <jglisse@redhat.com>
      Cc: linux-mm@kvack.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: Ralph Campbell <rcampbell@nvidia.com> #v1
      4fe51e9e
    • Thomas Hellstrom's avatar
      mm: Add an apply_to_pfn_range interface · 29875a52
      Thomas Hellstrom authored
      This is basically apply_to_page_range with added functionality:
      Allocating missing parts of the page table becomes optional, which
      means that the function can be guaranteed not to error if allocation
      is disabled. Also passing of the closure struct and callback function
      becomes different and more in line with how things are done elsewhere.
      
      Finally we keep apply_to_page_range as a wrapper around apply_to_pfn_range
      
      The reason for not using the page-walk code is that we want to perform
      the page-walk on vmas pointing to an address space without requiring the
      mmap_sem to be held rather than on vmas belonging to a process with the
      mmap_sem held.
      
      Notable changes since RFC:
      Don't export apply_to_pfn range.
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rik van Riel <riel@surriel.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Souptick Joarder <jrdr.linux@gmail.com>
      Cc: "Jérôme Glisse" <jglisse@redhat.com>
      Cc: linux-mm@kvack.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: Ralph Campbell <rcampbell@nvidia.com> #v1
      29875a52
    • Thomas Hellstrom's avatar
      mm: Allow the [page|pfn]_mkwrite callbacks to drop the mmap_sem · c9e5f41f
      Thomas Hellstrom authored
      Driver fault callbacks are allowed to drop the mmap_sem when expecting
      long hardware waits to avoid blocking other mm users. Allow the mkwrite
      callbacks to do the same by returning early on VM_FAULT_RETRY.
      
      In particular we want to be able to drop the mmap_sem when waiting for
      a reservation object lock on a GPU buffer object. These locks may be
      held while waiting for the GPU.
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rik van Riel <riel@surriel.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Souptick Joarder <jrdr.linux@gmail.com>
      Cc: "Jérôme Glisse" <jglisse@redhat.com>
      Cc: linux-mm@kvack.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: default avatarRalph Campbell <rcampbell@nvidia.com>
      c9e5f41f
    • Thomas Hellstrom's avatar
      drm/vmwgfx: Assign eviction priorities to resources · 4251fa5f
      Thomas Hellstrom authored
      TTM provides a means to assign eviction priorities to buffer object. This
      means that all buffer objects with a lower priority will be evicted first
      on memory pressure.
      Use this to make sure surfaces and in particular non-dirty surfaces are
      evicted first. Evicting in particular shaders, cotables and contexts imply
      a significant performance hit on vmwgfx, so make sure these resources are
      evicted last.
      Some buffer objects are sub-allocated in user-space which means we can have
      many resources attached to a single buffer object or resource. In that case
      the buffer object is given the highest priority of the attached resources.
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: default avatarDeepak Rawat <drawat@vmware.com>
      Reviewed-by: default avatarEmil Velikov <emil.velikov@collabora.com>
      4251fa5f
  2. 11 Jun, 2019 2 commits
  3. 10 Jun, 2019 7 commits
  4. 08 Jun, 2019 3 commits
  5. 07 Jun, 2019 12 commits
  6. 06 Jun, 2019 8 commits
  7. 05 Jun, 2019 1 commit