search for: vm_dontdump

...ge(struct vm_area_struct *vma, unsigned long addr, > unsigned long pfn, unsigned long size, pgprot_t prot) > { > if (addr != (pfn << PAGE_SHIFT)) > return -EINVAL; > > vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; > return 0; > } > EXPORT_SYMBOL(remap_pfn_range); > > > So things aren't going to work if you have a fixed PFN > which is the case of the hardware device. Looking at the implementation of some drivers e.g mtd_char. If I read the code correctly, we can do this b...

...ge(struct vm_area_struct *vma, unsigned long addr, > unsigned long pfn, unsigned long size, pgprot_t prot) > { > if (addr != (pfn << PAGE_SHIFT)) > return -EINVAL; > > vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; > return 0; > } > EXPORT_SYMBOL(remap_pfn_range); > > > So things aren't going to work if you have a fixed PFN > which is the case of the hardware device. Looking at the implementation of some drivers e.g mtd_char. If I read the code correctly, we can do this b...

On 2020/6/2 ??12:56, Michael S. Tsirkin wrote: > On Tue, Jun 02, 2020 at 03:22:49AM +0800, kbuild test robot wrote: >> Hi Jason, >> >> I love your patch! Yet something to improve: >> >> [auto build test ERROR on vhost/linux-next] >> [also build test ERROR on linus/master v5.7 next-20200529] >> [if your patch is applied to the wrong git tree, please drop

On 2020/6/2 ??12:56, Michael S. Tsirkin wrote: > On Tue, Jun 02, 2020 at 03:22:49AM +0800, kbuild test robot wrote: >> Hi Jason, >> >> I love your patch! Yet something to improve: >> >> [auto build test ERROR on vhost/linux-next] >> [also build test ERROR on linus/master v5.7 next-20200529] >> [if your patch is applied to the wrong git tree, please drop

...- /* VM_PFNMAP was set by drm_gem_mmap() */ > > - vma->vm_flags &= ~VM_PFNMAP; > > - vma->vm_flags |= VM_MIXEDMAP; > > + vma->vm_flags |= (VM_MIXEDMAP|VM_DONTEXPAND); > > I'm finding this a bit hard to follow - but I think here we've lost > VM_IO and VM_DONTDUMP which used to be set by drm_gem_mmap(). Yep. Intentional, but I think I better split that off to a separate patch with a commit message explaining things. > Also it looks like nothing is fiddling vma->vm_page_prot anymore. Oops, that one was not intentional. Will fix. cheers, Gerd

...h the patch described in that bug allows for blktap to build properly. Diff for reference: --- ring.c.orig 2013-10-26 23:53:39.300000000 +0900 +++ ring.c 2013-10-26 20:35:26.301000000 +0900 @@ -39,6 +39,10 @@ */ #define RING_PAGES 1 +#ifndef VM_RESERVED +# define VM_RESERVED (VM_DONTEXPAND | VM_DONTDUMP) +#endif + #define BLKTAP_INFO_SIZE_AT(_memb) \ offsetof(struct blktap_device_info, _memb) + \ sizeof(((struct blktap_device_info*)0)->_memb) -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kerne...

...Thanks Well int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn, unsigned long size, pgprot_t prot) { if (addr != (pfn << PAGE_SHIFT)) return -EINVAL; vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; return 0; } EXPORT_SYMBOL(remap_pfn_range); So things aren't going to work if you have a fixed PFN which is the case of the hardware device. > > > > > > >

...unsigned long addr, > > unsigned long pfn, unsigned long size, pgprot_t prot) > > { > > if (addr != (pfn << PAGE_SHIFT)) > > return -EINVAL; > > > > vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; > > return 0; > > } > > EXPORT_SYMBOL(remap_pfn_range); > > > > > > So things aren't going to work if you have a fixed PFN > > which is the case of the hardware device. > > > Looking at the implementation of some drivers e.g mtd_c...

...if (ret) { @@ -545,9 +536,10 @@ int drm_gem_shmem_mmap(struct file *filp, struct vm_area_struct *vma) return ret; } - /* VM_PFNMAP was set by drm_gem_mmap() */ - vma->vm_flags &= ~VM_PFNMAP; - vma->vm_flags |= VM_MIXEDMAP; + vma->vm_flags |= VM_IO | VM_MIXEDMAP | VM_DONTEXPAND | VM_DONTDUMP; + vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); + vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); + vma->vm_ops = &drm_gem_shmem_vm_ops; /* Remove the fake offset */ vma->vm_pgoff -= drm_vma_node_start(&shmem->base.vma_node);...

...if (ret) { @@ -545,9 +536,10 @@ int drm_gem_shmem_mmap(struct file *filp, struct vm_area_struct *vma) return ret; } - /* VM_PFNMAP was set by drm_gem_mmap() */ - vma->vm_flags &= ~VM_PFNMAP; - vma->vm_flags |= VM_MIXEDMAP; + vma->vm_flags |= VM_IO | VM_MIXEDMAP | VM_DONTEXPAND | VM_DONTDUMP; + vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); + vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); + vma->vm_ops = &drm_gem_shmem_vm_ops; /* Remove the fake offset */ vma->vm_pgoff -= drm_vma_node_start(&shmem->base.vma_node);...

...if (ret) { @@ -545,9 +536,10 @@ int drm_gem_shmem_mmap(struct file *filp, struct vm_area_struct *vma) return ret; } - /* VM_PFNMAP was set by drm_gem_mmap() */ - vma->vm_flags &= ~VM_PFNMAP; - vma->vm_flags |= VM_MIXEDMAP; + vma->vm_flags |= VM_IO | VM_MIXEDMAP | VM_DONTEXPAND | VM_DONTDUMP; + vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); + vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); + vma->vm_ops = &drm_gem_shmem_vm_ops; /* Remove the fake offset */ vma->vm_pgoff -= drm_vma_node_start(&shmem->base.vma_node);...

Hi, this work is based on the virtio_wl driver in the ChromeOS kernel by Zach Reizner, currently at: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c There's one feature missing currently, which is letting clients write directly to the host part of a resource, so the extra copy in TRANSFER_TO_HOST isn't needed. Have pushed the

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