Re: [Xen-devel] [PATCHv2 0/2] xen/privcmd: prevent page migration for hypercall buffers
On 04/08/16 16:16, David Vrabel wrote: > Currently libxencall using mlocked buffers for hypercall buffers. > This pages are subject to compaction and page migration. A userspace > process may see a hypercall fail with -EFAULT if a page backing a > hypercall buffer is in the process of being migrated. > > Page migration can be prevented by taking an additional reference to > the page. > > There are three possible ways to do this: > > 1. Add a new device which when mmap()'d populated the VMA with >suitable memory that has an additional reference. This would give >VMAs that have appropriate properties set (e.g., VM_DONTCOPY) >without having to do additional madvise() calls. > > 2. Add a new ioctl to privcmd to populate a VMA with suitably >ref-counted pages. However, mmap() on privcmd is already used for >foreign mappings and the VMA properties for hypercall buffers and >foreign mappings might need to be different and the handling of >unmap will need to be different. This might be tricky. > > 3. Add a pair of ioctls to privcmd to lock/unlock a buffer by >getting/putting an additional reference to the page. This is >what's implemented in this series. This method appears to be insufficient -- I'm still seeing very occasional, spurious -EFAULT errors. The easiest workaround is to set vm.compact_unevictable_allowed = 0. David ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv2 0/2] xen/privcmd: prevent page migration for hypercall buffers
On 22/08/16 19:25, David Vrabel wrote: > On 04/08/16 16:16, David Vrabel wrote: >> Currently libxencall using mlocked buffers for hypercall buffers. >> This pages are subject to compaction and page migration. A userspace >> process may see a hypercall fail with -EFAULT if a page backing a >> hypercall buffer is in the process of being migrated. >> >> Page migration can be prevented by taking an additional reference to >> the page. >> >> There are three possible ways to do this: >> >> 1. Add a new device which when mmap()'d populated the VMA with >>suitable memory that has an additional reference. This would give >>VMAs that have appropriate properties set (e.g., VM_DONTCOPY) >>without having to do additional madvise() calls. >> >> 2. Add a new ioctl to privcmd to populate a VMA with suitably >>ref-counted pages. However, mmap() on privcmd is already used for >>foreign mappings and the VMA properties for hypercall buffers and >>foreign mappings might need to be different and the handling of >>unmap will need to be different. This might be tricky. >> >> 3. Add a pair of ioctls to privcmd to lock/unlock a buffer by >>getting/putting an additional reference to the page. This is >>what's implemented in this series. >> >> Any thoughts on which is the best approach? > > Did no one have an opinions on these three options? I think 3 is the best solution. So for this series: Acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv2 0/2] xen/privcmd: prevent page migration for hypercall buffers
On 04/08/16 16:16, David Vrabel wrote: > Currently libxencall using mlocked buffers for hypercall buffers. > This pages are subject to compaction and page migration. A userspace > process may see a hypercall fail with -EFAULT if a page backing a > hypercall buffer is in the process of being migrated. > > Page migration can be prevented by taking an additional reference to > the page. > > There are three possible ways to do this: > > 1. Add a new device which when mmap()'d populated the VMA with >suitable memory that has an additional reference. This would give >VMAs that have appropriate properties set (e.g., VM_DONTCOPY) >without having to do additional madvise() calls. > > 2. Add a new ioctl to privcmd to populate a VMA with suitably >ref-counted pages. However, mmap() on privcmd is already used for >foreign mappings and the VMA properties for hypercall buffers and >foreign mappings might need to be different and the handling of >unmap will need to be different. This might be tricky. > > 3. Add a pair of ioctls to privcmd to lock/unlock a buffer by >getting/putting an additional reference to the page. This is >what's implemented in this series. > > Any thoughts on which is the best approach? Did no one have an opinions on these three options? David ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCHv2 0/2] xen/privcmd: prevent page migration for hypercall buffers
Currently libxencall using mlocked buffers for hypercall buffers. This pages are subject to compaction and page migration. A userspace process may see a hypercall fail with -EFAULT if a page backing a hypercall buffer is in the process of being migrated. Page migration can be prevented by taking an additional reference to the page. There are three possible ways to do this: 1. Add a new device which when mmap()'d populated the VMA with suitable memory that has an additional reference. This would give VMAs that have appropriate properties set (e.g., VM_DONTCOPY) without having to do additional madvise() calls. 2. Add a new ioctl to privcmd to populate a VMA with suitably ref-counted pages. However, mmap() on privcmd is already used for foreign mappings and the VMA properties for hypercall buffers and foreign mappings might need to be different and the handling of unmap will need to be different. This might be tricky. 3. Add a pair of ioctls to privcmd to lock/unlock a buffer by getting/putting an additional reference to the page. This is what's implemented in this series. Any thoughts on which is the best approach? Changes in v2: - Addressed Jan's feedback for #2 (see patch for details). David ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel