Re: [Xen-devel] [PATCHv2 0/2] xen/privcmd: prevent page migration for hypercall buffers

[David Vrabel]

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

[Juergen Gross]

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

[David Vrabel]

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