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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/08/16 09:46, Jan Beulich wrote:
>>>> 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.

There were some very hacky patches around 5 years ago which allowed 64
bit PV guests to execute the compat hypercall entry in Xen, for the
purpose of making 32bit userspace work in a 64bit guest under 64bit Xen.

The modifications required bypassing the hypercall page in the guest
kernel to execute `int $0x82` rather than `syscall`, and modifications
in Xen to follow the hypercall path rather than bounce `int $0x82` back
into the guest.

As for now, this is not something which functions in the slightest.  The
bitness of hypercall-aware userspace must match the bitness of the guest
kernel it is running under.

~Andrew

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