search for: nvif_vmm_pfnmap_v0_

On 8/10/19 4:13 AM, Christoph Hellwig wrote: > On something vaguely related to this patch: > > You use the NVIF_VMM_PFNMAP_V0_V* defines from nvif/if000c.h, which are > a little odd as we only ever set these bits, but they also don't seem > to appear to be in values that are directly fed to the hardware. > > On the other hand mmu/vmm.h defines a set of NVIF_VMM_PFNMAP_V0_* Yes, I see NVKM_VMM_PFN_* >...

...fferent nouveau internal representation. > + */ Nice callchain from hell.. Unfortunately such "code listings" tend to get out of date very quickly, so I'm not sure it is worth keeping in the code. What would be really worthile is consolidating the two different sets of defines (NVIF_VMM_PFNMAP_V0_ vs NVKM_VMM_PFN_) to make the code a little easier to follow. > npages = (range->end - range->start) >> PAGE_SHIFT; > for (i = 0; i < npages; ++i) { > struct page *page; > > + if (!(range->hmm_pfns[i] & HMM_PFN_VALID)) { > + ioctl_addr[i] = 0; &g...

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.

...read. >> Why not "pfns + i"? > > OK, will do in v2. > Should I convert to "dma_addrs + nr_dma" too? I'll fix it up for v3 of the migrate_vma series. This is a leftover from passing an args structure. On something vaguely related to this patch: You use the NVIF_VMM_PFNMAP_V0_V* defines from nvif/if000c.h, which are a little odd as we only ever set these bits, but they also don't seem to appear to be in values that are directly fed to the hardware. On the other hand mmu/vmm.h defines a set of NVIF_VMM_PFNMAP_V0_* constants with similar names and identical values, an...

On Mon, Aug 12, 2019 at 12:42:30PM -0700, Ralph Campbell wrote: > > On 8/10/19 4:13 AM, Christoph Hellwig wrote: >> On something vaguely related to this patch: >> >> You use the NVIF_VMM_PFNMAP_V0_V* defines from nvif/if000c.h, which are >> a little odd as we only ever set these bits, but they also don't seem >> to appear to be in values that are directly fed to the hardware. >> >> On the other hand mmu/vmm.h defines a set of NVIF_VMM_PFNMAP_V0_* > > Yes, I s...

...2019 at 5:11 PM Christoph Hellwig <hch at lst.de> wrote: > > On Mon, Aug 12, 2019 at 12:42:30PM -0700, Ralph Campbell wrote: > > > > On 8/10/19 4:13 AM, Christoph Hellwig wrote: > >> On something vaguely related to this patch: > >> > >> You use the NVIF_VMM_PFNMAP_V0_V* defines from nvif/if000c.h, which are > >> a little odd as we only ever set these bits, but they also don't seem > >> to appear to be in values that are directly fed to the hardware. > >> > >> On the other hand mmu/vmm.h defines a set of NVIF_VMM_PFNMAP_V0_...

...sentation. > > + */ > > Nice callchain from hell.. Unfortunately such "code listings" tend to > get out of date very quickly, so I'm not sure it is worth keeping in > the code. What would be really worthile is consolidating the two > different sets of defines (NVIF_VMM_PFNMAP_V0_ vs NVKM_VMM_PFN_) > to make the code a little easier to follow. I was mainly concerned that this function is using hmm properly, becuase it sure looks like it is just forming the CPU physical address into a HW specific data. But it turns out it is just an internal data for some other code and t...

From: Jason Gunthorpe <jgg at mellanox.com> The API is a bit complicated for the uses we actually have, and disucssions for simplifying have come up a number of times. This small series removes the customizable pfn format and simplifies the return code of hmm_range_fault() All the drivers are adjusted to process in the simplified format. I would appreciated tested-by's for the two