Re: Device model operation hypercall (DMOP, re qemu depriv)

["Jan Beulich" <JBeulich@suse.com>]

>>> On 09.09.16 at 17:16, <Jennifer.Herbert@citrix.com> wrote:
> The following code illustrates this idea:
> 
> typedef struct dm_op_buffer {
>      XEN_GUEST_HANDLE(void) h;
>      size_t len;
> } dm_op_buffer_t;

This implies that we'll lose all type safety on the handles passed, as
is also emphasized by the use of raw_copy_from_guest() in the code
outline further down.

> int
> HYPERVISOR_device_model_op(
>      domid_t domid,
>      unsigned int nr_buffers,
>      XEN_GUEST_HANDLE_PARAM(dm_op_buffer_t) buffers)

Along the same lines this will add implicit agreements (presumably
solely written out as comments, or maybe via manifest constants)
about which element of the buffer array has which meaning, quite
contrary to the otherwise enforced agreement (through use of
structure fields).

> int copy_dm_buffer_from_guest(
>      void *dst,                        /* Kernel destination buffer      */
>      size_t max_len,                   /* Size of destination buffer     */
>      XEN_GUEST_HANDLE_PARAM(dm_op_buffer_t) buffers,
>                                        /* dm_op_buffers passed into DMOP */
>      unsigned int nr_buffers,          /* total number of dm_op_buffers  */
>      unsigned int idx)                 /* Index of buffer we require     */

Looking at other hypercalls, it is not uncommon that arrays get
read element by element. While of course this function can be
extended suitably (perhaps with additional macro wrappers to
deal with the base types of such arrays), it will then become more
cumbersome to use, extending the "Minor stylistic issue" mentioned
in the disadvantages section further down.

Jan


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