search for: nouveau_vm_map_sg

...ct > (and thus I'm on the right track) : This patch (which needs cleanups, and probably be broken down for bisectability) makes it work for me. I've disabled nouveau_dri for now as this has its own problems related to Ajax recent gallium endian changes. Note the horrible duplication of nouveau_vm_map_sg... I think to fix it "cleanly" we probably need to slightly change the ->map_sg API to the vmmr. However, I do have a question whose answer might make things a LOT easier if "yes" can make things a lot easier: Can we guarantee that that such an sg object (I assume this is a...

...39;s going on, but this is just a straightforward way to avoid a null deref that you see happens in the bug. I haven't figured out the root cause of this, but it's getting well into the "I have no idea how TTM works" space. However this seems like a bit of defensive programming -- nouveau_vm_map_sg will pass node->pages as a list down, which will be dereferenced by nvc0_vm_map_sg. Perhaps the other arguments should make that dereferencing not happen, but it definitely was happening here, as you can see in the bug. Ben/Maarten, I'll let you judge whether this check is appropriate, sinc...

...h mapping a piece of card > address space in the card VM and thus shouldn't be concerned by the > system PAGE_SIZE at all, right ? Former, but the code entangles system PAGE_SIZE and card PAGE_SIZE/SHIFT/MASK in some cases. > IE. The only one we should actually care about here is > nouveau_vm_map_sg_table() or am I missing an important piece of the > puzzle ? nouveau_vm_map_sg too. nouveau_vm_map is special, and also used to map VRAM into BAR1/BAR3 by subdev/bar code. > Additionally, nv41.c has only map_sg() callbacks, no map() callbacks, > should I assume that means that nouveau_vm_...

...the right track) : > This patch (which needs cleanups, and probably be broken down for > bisectability) makes it work for me. I've disabled nouveau_dri for now > as this has its own problems related to Ajax recent gallium endian > changes. > > Note the horrible duplication of nouveau_vm_map_sg... > > I think to fix it "cleanly" we probably need to slightly change the > ->map_sg API to the vmmr. However, I do have a question whose answer > might make things a LOT easier if "yes" can make things a lot easier: > > Can we guarantee that that such an s...

...his is just a > straightforward way to avoid a null deref that you see happens in the > bug. I haven't figured out the root cause of this, but it's getting > well into the "I have no idea how TTM works" space. However this seems > like a bit of defensive programming -- nouveau_vm_map_sg will pass > node->pages as a list down, which will be dereferenced by > nvc0_vm_map_sg. Perhaps the other arguments should make that > dereferencing not happen, but it definitely was happening here, as you > can see in the bug. > > Ben/Maarten, I'll let you judge whether th...

...iff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c > > index ef3133e..5833851 100644 > > --- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c > > +++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c > > @@ -84,10 +84,11 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64 delta, u64 length, > > { > > struct nouveau_vm *vm = vma->vm; > > struct nouveau_vmmgr *vmm = vm->vmm; > > - int big = vma->node->type != vmm->spg_shift; > > + u32 shift = vma->node->type; > > + int big...

...ers/gpu/drm/nouveau/core/subdev/vm/base.c b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c >> > index ef3133e..5833851 100644 >> > --- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c >> > +++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c >> > @@ -84,10 +84,11 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64 delta, u64 length, >> > { >> > struct nouveau_vm *vm = vma->vm; >> > struct nouveau_vmmgr *vmm = vm->vmm; >> > - int big = vma->node->type != vmm->spg_shift; >> > + u32 shift = vma->node-&...

...index 160d27f..9907a25 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c +++ b/drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c @@ -67,7 +67,10 @@ nv50_bar_umap(struct nouveau_bar *bar, struct nouveau_mem *mem, if (ret) return ret; - nouveau_vm_map(vma, mem); + if (mem->pages) + nouveau_vm_map_sg(vma, 0, mem->size << 12, mem); + else + nouveau_vm_map(vma, mem); return 0; } diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c index b2ec741..badd835 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c +++ b/drivers/...

...gt; straightforward way to avoid a null deref that you see happens in the > > bug. I haven't figured out the root cause of this, but it's getting > > well into the "I have no idea how TTM works" space. However this seems > > like a bit of defensive programming -- nouveau_vm_map_sg will pass > > node->pages as a list down, which will be dereferenced by > > nvc0_vm_map_sg. Perhaps the other arguments should make that > > dereferencing not happen, but it definitely was happening here, as you > > can see in the bug. > > > > Ben/Maarten, I...

...t;> straightforward way to avoid a null deref that you see happens in the >> bug. I haven't figured out the root cause of this, but it's getting >> well into the "I have no idea how TTM works" space. However this seems >> like a bit of defensive programming -- nouveau_vm_map_sg will pass >> node->pages as a list down, which will be dereferenced by >> nvc0_vm_map_sg. Perhaps the other arguments should make that >> dereferencing not happen, but it definitely was happening here, as you >> can see in the bug. >> >> Ben/Maarten, I'll...

...to avoid a null deref that you see happens in the > >>> bug. I haven't figured out the root cause of this, but it's getting > >>> well into the "I have no idea how TTM works" space. However this seems > >>> like a bit of defensive programming -- nouveau_vm_map_sg will pass > >>> node->pages as a list down, which will be dereferenced by > >>> nvc0_vm_map_sg. Perhaps the other arguments should make that > >>> dereferencing not happen, but it definitely was happening here, as you > >>> can see in the bug. >...

...ay to avoid a null deref that you see happens in the >>>> bug. I haven't figured out the root cause of this, but it's getting >>>> well into the "I have no idea how TTM works" space. However this seems >>>> like a bit of defensive programming -- nouveau_vm_map_sg will pass >>>> node->pages as a list down, which will be dereferenced by >>>> nvc0_vm_map_sg. Perhaps the other arguments should make that >>>> dereferencing not happen, but it definitely was happening here, as you >>>> can see in the bug. >>...

...>mem_type == TTM_PL_TT && - nvbo->page_shift == vma->vm->vmm->spg_shift) { + } else if (new_mem->mem_type == TTM_PL_TT && + nvbo->page_shift == vma->vm->vmm->spg_shift) { if (((struct nouveau_mem *)new_mem->mm_node)->sg) nouveau_vm_map_sg_table(vma, 0, new_mem-> num_pages << PAGE_SHIFT, @@ -1153,8 +1163,6 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct ttm_mem_reg *new_mem) nouveau_vm_map_sg(vma, 0, new_mem-> num_pages << PAGE_SHIFT, new_mem->mm_node); - } else { -...

...ap_sg() which was trying to handle the case at that low level, but this isn't enough, and after a bit of digging, I also think that's not the right approach: So, from what I can tell, subdev/vm/base.c is not clean vs. PAGE_SIZE in a number of places unless I'm mistaken. For example, in nouveau_vm_map_sg_table(), something like that: sglen = sg_dma_len(sg) >> PAGE_SHIFT; end = pte + sglen; Seems to imply an assumption here that the "pte" is in multiple of PAGE_SHIFT, but afaik, it's not. So further down, we do: for (m = 0; m < len; m++) { dma_addr_t addr = sg_dma...

...his is just a > straightforward way to avoid a null deref that you see happens in the > bug. I haven't figured out the root cause of this, but it's getting > well into the "I have no idea how TTM works" space. However this seems > like a bit of defensive programming -- nouveau_vm_map_sg will pass > node->pages as a list down, which will be dereferenced by > nvc0_vm_map_sg. Perhaps the other arguments should make that > dereferencing not happen, but it definitely was happening here, as you > can see in the bug. > > Ben/Maarten, I'll let you judge whether th...

...ed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c index 7dd680f..db35e8d 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c +++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c @@ -152,13 +152,18 @@ nouveau_vm_map_sg(struct nouveau_vma *vma, u64 delta, u64 length, end = (pte + num); if (unlikely(end >= max)) end = max; - len = end - pte; + + /* + * Map pages >4KB one by one so we can fix the list pointer + * as to not map intermediate pages to the next PTE + */ + len = bits ? 1 : end -...

...em) + continue; + + if (new_mem->mem_type == TTM_PL_VRAM) { nouveau_vm_map(vma, new_mem->mm_node); } else if (new_mem && new_mem->mem_type == TTM_PL_TT && @@ -1185,8 +1193,6 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct ttm_mem_reg *new_mem) nouveau_vm_map_sg(vma, 0, new_mem-> num_pages << PAGE_SHIFT, new_mem->mm_node); - } else { - nouveau_vm_unmap(vma); } } } -- 1.8.3.4

...ull deref that you see happens in the >> >>> bug. I haven't figured out the root cause of this, but it's getting >> >>> well into the "I have no idea how TTM works" space. However this seems >> >>> like a bit of defensive programming -- nouveau_vm_map_sg will pass >> >>> node->pages as a list down, which will be dereferenced by >> >>> nvc0_vm_map_sg. Perhaps the other arguments should make that >> >>> dereferencing not happen, but it definitely was happening here, as you >> >>> can see...

...that you see happens in the >>>>>> bug. I haven't figured out the root cause of this, but it's getting >>>>>> well into the "I have no idea how TTM works" space. However this seems >>>>>> like a bit of defensive programming -- nouveau_vm_map_sg will pass >>>>>> node->pages as a list down, which will be dereferenced by >>>>>> nvc0_vm_map_sg. Perhaps the other arguments should make that >>>>>> dereferencing not happen, but it definitely was happening here, as you >>>>>&...

...ward way to avoid a null deref that you see happens in the > > > bug. I haven't figured out the root cause of this, but it's getting > > > well into the "I have no idea how TTM works" space. However this seems > > > like a bit of defensive programming -- nouveau_vm_map_sg will pass > > > node->pages as a list down, which will be dereferenced by > > > nvc0_vm_map_sg. Perhaps the other arguments should make that > > > dereferencing not happen, but it definitely was happening here, as you > > > can see in the bug. > > > &...