Re: [Xen-devel] [PATCHv2 2/2] xen/privcmd: add ioctls for locking/unlocking hypercall buffers

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.08.16 at 19:24, <david.vrabel@xxxxxxxxxx> wrote:
> On 04/08/16 17:02, Jan Beulich wrote:
>>>>> On 04.08.16 at 17:16, <david.vrabel@xxxxxxxxxx> wrote:
>>> Using mlock() for hypercall buffers is not sufficient since mlocked
>>> pages are still subject to compaction and page migration.  Page
>>> migration can be prevented by taking additional references to the
>>> pages.
>>>
>>> Introduce two new ioctls: IOCTL_PRIVCMD_HCALL_BUF_LOCK and
>>> IOCTL_PRIVCMD_HCALL_BUF_UNLOCK which get and put the necessary page
>>> references.  The buffers do not need to be page aligned and they may
>>> overlap with other buffers.  However, it is not possible to partially
>>> unlock a buffer (i.e., the LOCK/UNLOCK must always be paired).  Any
>>> locked buffers are automatically unlocked when the file descriptor is
>>> closed.
>>>
>>> An alternative approach would be to extend the driver with an ioctl to
>>> populate a VMA with "special", non-migratable pages.  But the
>>> LOCK/UNLOCK ioctls are more flexible as they allow any page to be used
>>> for hypercalls (e.g., stack, mmap'd files, etc.).  This could be used
>>> to minimize bouncing for performance critical hypercalls.
>>>
>>> Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
>> 
>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>> 
>> with two remarks: Do you not care about compat mode callers?
> 
> No.  Compat mode callers can't make hypercalls since the hypervisor ABI
> structures aren't converted anywhere.

Hmm - is putting a 64-bit kernel underneath a 32-bit installation
something that works for all other purposes, but is meant to
explicitly not work with Xen? The domctl/sysctl model (which the
hvmctl series follows, since the earlier hvmop already has this
requirement) already requires no translation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel