|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH v2 07/17] libxl: add save/restore support for qemu-xen in stubdomain
Marek Marczykowski-Górecki writes ("[RFC PATCH v2 07/17] libxl: add
save/restore support for qemu-xen in stubdomain"):
> Rely on a wrapper script in stubdomain to attach FD 3/4 of qemu to
> relevant consoles.
...
> if (state->saved_state) {
> - /* This file descriptor is meant to be used by QEMU */
> - *dm_state_fd = open(state->saved_state, O_RDONLY);
> - flexarray_append(dm_args, "-incoming");
> - flexarray_append(dm_args, GCSPRINTF("fd:%d",*dm_state_fd));
> + if (is_stubdom) {
> + /* Linux stubdomain connects specific FD to
> STUBDOM_CONSOLE_RESTORE
> + */
> + flexarray_append(dm_args, "-incoming");
> + flexarray_append(dm_args, "fd:3");
I think this hardcoded fd is troublesome. For example, we don't have
anywhere to write down the list of hardcoded fds being used like this.
I mean, libxl and the Linux qemu stubdom wrapper script are allowed to
cooperate, but at least this needs a clear comment in the wrapper
script, and a reference here to the in-tree location of the script.
I'm missing the code which is transfers the data from the
state->saved_state to the console. Am I just being dim ?
> diff --git a/tools/libxl/libxl_dom_suspend.c b/tools/libxl/libxl_dom_suspend.c
...
> /* Save DM state into filename */
> + if (dm_domid) {
> + /* if DM is in stubdomain, instruct it to use console, which is
> + * connected to a file pointed by filename */
> + filename = "/proc/self/fd/4";
Same comment (mutatis mutandi).
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |