similar to: [PATCH] direct_remap_pfn_range vm_flags fix

The only time when granted pages need to be treated specially is when using Xen''s PTE modification for grant mappings owned by another domain. Otherwise, the area does not require VM_DONTCOPY and VM_PFNMAP, since it can be accessed just like any other page of RAM. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> --- drivers/xen/gntalloc.c | 14 ++++++++++++--

Since when we are using the m2p_override it is not true anymore that the mmap''ed area doesn''t have corresponsing struct pages. Removing the VM_PFNMAP flag makes get_user_pages work on the mmap''ed user vma. An example test case would be using a Xen userspace block backend (QDISK) on a file on NFS using O_DIRECT. The patch should be backported back to 2.6.38.

On 02/10/19 19:04, Jerome Glisse wrote: > On Wed, Oct 02, 2019 at 06:18:06PM +0200, Paolo Bonzini wrote: >>>> If the mapping of the source VMA changes, mirroring can update the >>>> target VMA via insert_pfn. But what ensures that KVM's MMU notifier >>>> dismantles its own existing page tables (so that they can be recreated >>>> with the new

On 02/10/19 19:04, Jerome Glisse wrote: > On Wed, Oct 02, 2019 at 06:18:06PM +0200, Paolo Bonzini wrote: >>>> If the mapping of the source VMA changes, mirroring can update the >>>> target VMA via insert_pfn. But what ensures that KVM's MMU notifier >>>> dismantles its own existing page tables (so that they can be recreated >>>> with the new

I have a PCI device which can perform bus master DMA. I developed a PCI device driver which can allocate DMA buffer and provide mmap operation to map the I/O and DMA buffer to user space. The PCI device driver works well under Linux 2.6.20. However it brokes under XEN 3.0.4. It appears that mmap map to the wrong memory. remap_pfn_range in mmap function return no error when it is used to map

Since we are using the m2p_override we do have struct pages corresponding to the user vma mmap''ed by gntdev. Removing the VM_PFNMAP flag makes get_user_pages work on that vma. An example test case would be using a Xen userspace block backend (QDISK) on a file on NFS using O_DIRECT. The patch should be backported back to 2.6.38. Signed-off-by: Stefano Stabellini

On 2020/6/2 ??9:31, Michael S. Tsirkin wrote: > On Tue, Jun 02, 2020 at 02:49:38PM +0800, Jason Wang wrote: >> 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

On 2020/6/2 ??9:31, Michael S. Tsirkin wrote: > On Tue, Jun 02, 2020 at 02:49:38PM +0800, Jason Wang wrote: >> 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

Hi everyone, I am very excited to see that dom0 pvops is finally coming close to working, so I wanted to give it a try. >From the description it was not clear to me which kernel to chose as base for the patches.hg, so I took the latest (that was ~ 2 weeks ago) kernel on git.kernel.org I could find (post-2.6.28 git tip at that point). I managed to more or less apply all of the patches in the

This flag controls the meaning of gnttab_map_grant_ref.host_addr and specifies that the field contains a refernce to the pte entry to be used to perform the mapping. Therefore move the use of this flag to the point at which we actually use a reference to the pte instead of something else, splitting up the usage of the flag in this way is confusing and potentially error prone. The other flags are

Here are seven more patches for things I found to clean up. This was based on top of Christoph's seven patches: "hmm_range_fault related fixes and legacy API removal v3". I assume this will go into Jason's tree since there will likely be more HMM changes in this cycle. Changes from v1 to v2: Added AMD GPU to hmm_update removal. Added 2 patches from Christoph. Added 2 patches as

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

On Mon, Jul 20, 2020 at 01:49:09PM -0700, Ralph Campbell wrote: > > On 7/20/20 12:59 PM, Jason Gunthorpe wrote: > > On Mon, Jul 20, 2020 at 12:54:53PM -0700, Ralph Campbell wrote: > > > > > diff --git a/include/linux/migrate.h b/include/linux/migrate.h > > > > > index 3e546cbf03dd..620f2235d7d4 100644 > > > > > +++ b/include/linux/migrate.h

vm_normal_page() @ linux-2.6-xen-sparse/mm/memory.c ... if (!vma->vm_flags & VM_RESERVED) print_bad_pte(vma, pte, addr); note:VM_RESERVED=0x00080000 This if clause is always false. Should it be "if (!(vma->vm_flags & VM_RESERVED))" ? -- yamahata _______________________________________________ Xen-devel mailing list

Package: blktap-dkms Version: 2.0.93-0.1 Severity: serious Justification: fails to build from source (but built successfully in the past) blktap fails to build on kernel 3.13 and probably older kernels as well. According to this bug: https://bugs.launchpad.net/ubuntu/+source/blktap-dkms/+bug/1245009 VM_RESERVED is deprecated as of 3.7. Building with the patch described in that bug allows for

Package: blktap-dkms Version: 2.0.91-1 Severity: normal With both linux-image-3.2.0-4-amd64 and linux-image-3.16-2-amd64 installed, blktap fails to compile for the 3.16-2 kernel, but succeeds for the 3.2.0-4 kernel. (Contrary to the dependency listing below, I do have the headers for 3.16-2 installed.) I am attaching the build log. -- System Information: Debian Release: 7.6 APT prefers

On Thu, Oct 03, 2019 at 04:42:20PM +0000, Mircea CIRJALIU - MELIU wrote: > > On 03/10/19 17:42, Jerome Glisse wrote: > > > All that is needed is to make sure that vm_normal_page() will see > > > those pte (inside the process that is mirroring the other process) as > > > special which is the case either because insert_pfn() mark the pte as > > > special or

Package: blktap-dkms Severity: grave Justification: renders package unusable Hi, blktap-dkms FTBFS against linux 3.10-1 from unstable: Cheers, Moritz CC [M] /var/lib/dkms/blktap/2.0.91/build/control.o In file included from /var/lib/dkms/blktap/2.0.91/build/control.c:30:0: /var/lib/dkms/blktap/2.0.91/build/blktap.h:75:41: warning: variably modified ?pending? at file scope [enabled by

Hi, > > - /* 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