similar to: [PATCH] drm/nouveau: remove ghost file

From: Jérôme Glisse <jglisse at redhat.com> Allow userspace to create a virtual address range hole for GEM object. Signed-off-by: Jérôme Glisse <jglisse at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_ttm.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c index

On Thu, Aug 15, 2019 at 01:12:22PM -0700, Dan Williams wrote: > On Thu, Aug 15, 2019 at 12:44 PM Jerome Glisse <jglisse at redhat.com> wrote: > > > > On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams wrote: > > > On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse <jglisse at redhat.com> wrote: > > > > > > > > On Wed, Aug 14, 2019 at

From: Jérôme Glisse <jglisse at redhat.com> (mm is cced just to allow exposure of device driver work without ccing a long list of peoples. I do not think there is anything usefull to discuss from mm point of view but i might be wrong, so just for the curious :)). git://people.freedesktop.org/~glisse/linux branch: nouveau-hmm-v00

From: Jérôme Glisse <jglisse at redhat.com> Empty chunk do not have a bo associated with them so no need to pin/unpin on suspend/resume. This fix suspend/resume on 5.1rc1 when NOUVEAU_SVM is enabled. Signed-off-by: Jérôme Glisse <jglisse at redhat.com> Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> Tested-by: Tobias Klausmann

On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams wrote: > On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse <jglisse at redhat.com> wrote: > > > > On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote: > > > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe <jgg at mellanox.com> wrote: > > > > > > > > On Wed, Aug 14, 2019 at

On Thu, Mar 21, 2019 at 04:59:14PM +0100, Tobias Klausmann wrote: > Hi, > > just for your information and maybe for some help: with 5.1rc1 and SVM > enabled i see the following backtrace [1] when the nouveau card (reverse > prime) goes to sleep, for now i have papered over with [2] which leaves me > with userspace hangs. Any pointers where to look for the actual culprit? >

On Thu, Aug 15, 2019 at 12:44 PM Jerome Glisse <jglisse at redhat.com> wrote: > > On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams wrote: > > On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse <jglisse at redhat.com> wrote: > > > > > > On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote: > > > > On Wed, Aug 14, 2019 at 6:28 AM Jason

On Wed, Sep 11, 2019 at 03:28:27PM -0700, Ralph Campbell wrote: > Allow hmm_range_fault() to return success (0) when the CPU pagetable > entry points to the special shared zero page. > The caller can then handle the zero page by possibly clearing device > private memory instead of DMAing a zero page. > > Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> > Cc:

On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse <jglisse at redhat.com> wrote: > > On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote: > > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe <jgg at mellanox.com> wrote: > > > > > > On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig wrote: > > > > On Tue, Aug 13, 2019 at 06:36:33PM

On Wed, Apr 17, 2019 at 10:26:32PM +0800, Yue Haibing wrote: > From: YueHaibing <yuehaibing at huawei.com> > > During randconfig builds, I occasionally run into an invalid configuration > > WARNING: unmet direct dependencies detected for DEVICE_PRIVATE > Depends on [n]: ARCH_HAS_HMM_DEVICE [=n] && ZONE_DEVICE [=n] > Selected by [y]: > - DRM_NOUVEAU_SVM

On Tue, Jul 23, 2019 at 02:05:06PM -0700, Ralph Campbell wrote: > The hmm_mirror_ops callback function sync_cpu_device_pagetables() passes > a struct hmm_update which is a simplified version of struct > mmu_notifier_range. This is unnecessary so replace hmm_update with > mmu_notifier_range directly. > > Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> > Cc:

walk_page_range() will only call hmm_vma_walk_hugetlb_entry() for hugetlbfs pages and doesn't call hmm_vma_walk_pmd() in this case. Therefore, it is safe to remove the check for vma->vm_flags & VM_HUGETLB in hmm_vma_walk_pmd(). Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> Cc: "Jérôme Glisse" <jglisse at redhat.com> Cc: Jason Gunthorpe <jgg at

Since hmm_range_fault() doesn't use the struct hmm_range vma field, remove it. Suggested-by: Jason Gunthorpe <jgg at mellanox.com> Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> Cc: "Jérôme Glisse" <jglisse at redhat.com> Cc: Christoph Hellwig <hch at lst.de> --- drivers/gpu/drm/nouveau/nouveau_svm.c | 7 +++---- include/linux/hmm.h

Allow hmm_range_fault() to return success (0) when the CPU pagetable entry points to the special shared zero page. The caller can then handle the zero page by possibly clearing device private memory instead of DMAing a zero page. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> Cc: "Jérôme Glisse" <jglisse at redhat.com> Cc: Jason Gunthorpe <jgg at mellanox.com>

On Wed, Aug 07, 2019 at 08:02:14AM -0700, Ralph Campbell wrote: > When memory is migrated to the GPU it is likely to be accessed by GPU > code soon afterwards. Instead of waiting for a GPU fault, map the > migrated memory into the GPU page tables with the same access permissions > as the source CPU page table entries. This preserves copy on write > semantics. > >

The hmm_mirror_ops callback function sync_cpu_device_pagetables() passes a struct hmm_update which is a simplified version of struct mmu_notifier_range. This is unnecessary so replace hmm_update with mmu_notifier_range directly. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> Cc: "Jérôme Glisse" <jglisse at redhat.com> Cc: Jason Gunthorpe <jgg at mellanox.com>

On 8/8/19 12:07 AM, Christoph Hellwig wrote: > On Wed, Aug 07, 2019 at 08:02:14AM -0700, Ralph Campbell wrote: >> When memory is migrated to the GPU it is likely to be accessed by GPU >> code soon afterwards. Instead of waiting for a GPU fault, map the >> migrated memory into the GPU page tables with the same access permissions >> as the source CPU page table entries.

On Mon, Sep 16, 2019 at 04:35:30PM +0100, Ben Dooks wrote: > On 16/09/2019 16:04, Thierry Reding wrote: > > From: Thierry Reding <treding at nvidia.com> > > > > There are extra registers that need to be programmed to make the level 2 > > cache work on GP10B, such as the stream ID register that is used when an > > SMMU is used to translate memory addresses.

From: Jason Gunthorpe <jgg at mellanox.com> Now that we have KERNEL_HEADER_TEST all headers are generally compile tested, so relying on makefile tricks to avoid compiling code that depends on CONFIG_MMU_NOTIFIER is more annoying. Instead follow the usual pattern and provide most of the header with only the functions stubbed out when CONFIG_MMU_NOTIFIER is disabled. This ensures code

From: Jason Gunthorpe <jgg at mellanox.com> Now that we have KERNEL_HEADER_TEST all headers are generally compile tested, so relying on makefile tricks to avoid compiling code that depends on CONFIG_MMU_NOTIFIER is more annoying. Instead follow the usual pattern and provide most of the header with only the functions stubbed out when CONFIG_MMU_NOTIFIER is disabled. This ensures code