Re: [Xen-devel] [PATCH v4 12/16] libxl: use vchan for QMP access with Linux stubdomain

[Rich Persaud <persaur@gmail.com>]

On Jan 24, 2020, at 09:07, Jason Andryuk <jandryuk@gmail.com> wrote:
> 
> On Tue, Jan 21, 2020 at 6:46 PM Marek Marczykowski-Górecki
> <marmarek@invisiblethingslab.com> wrote:
> 
>>>> +
>>>> +    sdss->qmp_proxy_spawn.timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
>>>> +    sdss->qmp_proxy_spawn.midproc_cb = libxl__spawn_record_pid;
>>>> +    sdss->qmp_proxy_spawn.confirm_cb = qmp_proxy_confirm;
>>>> +    sdss->qmp_proxy_spawn.failure_cb = qmp_proxy_startup_failed;
>>>> +    sdss->qmp_proxy_spawn.detached_cb = qmp_proxy_detached;
>>>> +
>>>> +    const int arraysize = 6;
>>>> +    GCNEW_ARRAY(args, arraysize);
>>>> +    args[nr++] = STUBDOM_QMP_PROXY_PATH;
>>>> +    args[nr++] = GCSPRINTF("--state-path=%s", sdss->qmp_proxy_spawn.xspath);
>>>> +    args[nr++] = GCSPRINTF("%u", dm_domid);
>>>> +    args[nr++] = GCSPRINTF("%s/device-model/%u/qmp-vchan", dom_path, guest_domid);
>>> Thinking of OpenXT"s qmp-helper, this path isn't useful.  But it is
>>> for vchan-socket-proxy, so qmp-helper could just change to ignore it.
>> For vchan we could use also a port number (and then it will encode it
>> into a xenstore path). This is in fact how we use libvchan in Qubes. I
>> opted for explicit path only because of lack of idea for some meaningful
>> port number ;) But I'm open for suggestions.
>> I guess that would be useful for Argo version then.
> 
> The argo version hard codes the port number, so it's not a command
> line argument.  The port number would need to get passed to the
> stubdom or it would need to be standardized.
> 
> I think the arguments for vchan-socket-proxy make sense.  Since it's
> the one that's submitted upstream, it makes sense to use them.
> 
> Put another way, do we want this to support alternate implementations
> for a qmp proxy?  Should the arguments be generic for that case?


One advantage of the server+client approach of vchan-socket-proxy is the absence of patches for Qemu.  OpenXT qmp-helper requires a Qemu patch for Argo support.  If there was a qmp socket proxy with Argo support, unpatched Qemu could be used with libxl and Argo access controls.

A generalized qmp-socket-proxy may be useful to other projects.  It would be good if the design supported single-purpose (client or server) binaries, e.g. common functions in a library shared by separate client and server source files, with conditional compilation for vchan and Argo interfaces.

Rich
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel