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

[David Vrabel <david.vrabel@citrix.com>]

On 02/08/16 12:58, Jan Beulich wrote:
>>>> On 02.08.16 at 13:38, <wei.liu2@citrix.com> wrote:
>> On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote:
>>>>>> On 01.08.16 at 13:32, <ian.jackson@eu.citrix.com> wrote:
>>>> 4. We could invent a new hypercall `DMOP' for hypercalls which device
>>>>    models should be able to use, which always has the target domain in
>>>>    a fixed location in the arguments.  We have the dom0 privcmd driver
>>>>    know about this one hypercall number and the location of the target
>>>>    domid.
>>>>
>>>> Option 4 has the following advantages:
>>>>
>>>> * The specification of which hypercalls are authorised to qemu is
>>>>   integrated with the specification of the hypercalls themselves:
>>>>   There is no need to maintain a separate table which can get out of
>>>>   step (or contain security bugs).
>>>>
>>>> * The changes required to the rest of the system are fairly small.
>>>>   In particular:
>>>>
>>>> * We need only one small, non-varying, patch to the dom0 kernel.
>>>>
>>>>
>>>> Let me flesh out option 4 in more detail:
>>>>
>>>>
>>>> We define a new hypercall DMOP.
>>>>
>>>> Its first argument is always a target domid.  The DMOP hypercall
>>>> number and position of the target domid in the arguments are fixed.
>>>>
>>>> A DMOP is defined to never put at risk the stability or security of
>>>> the whole system, nor of the domain which calls DMOP.  However, a DMOP
>>>> may have arbitrary effects on the target domid.
>>>
>>> With the exception of this and the privcmd layer described below,
>>> DMOP == HVMCTL afaics. The privcmd layer is independent anyway.
>>> And the security aspect mentioned above won't disappear if we
>>> use DMOP instead of HVMCTL. So I don't see why the hvmctl
>>> series as is can't be the starting point of this, with the stability/
>>> security concerns addressed subsequently, for being orthogonal.
>>>
>>
>> Yeah, to turn HVMCTL to DMOP:
>>
>> 1. s/HVMCTL/DMOP/
>> 2. maybe s/interface_version//
> 
> Andrew had brought up 2 too, but I'm really not sure that'd be a
> good idea. I rather think we should keep it but maybe (other than
> domctl/sysctl) recognize older versions. In any event I consider
> having it better for an unstable interface (as Ian said, libxc is
> supposed to provide the stable one).

A stable user space library API is no good for an in-kernel emulator,
like that needed for Intel GVT-g -- the hypercall ABI needs to be stable.

David

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