|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v5 09/21] libxl: add save/restore support for qemu-xen in stubdomain
Jason Andryuk writes ("[PATCH v5 09/21] libxl: add save/restore support for
qemu-xen in stubdomain"):
> From: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
>
> Rely on a wrapper script in stubdomain to attach FD 3/4 of qemu to
> relevant consoles.
>
> Signed-off-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> Address TODO in dm_state_save_to_fdset: Only remove savefile for
> non-stubdom.
...
> + if (is_stubdom) {
> + /* Linux stubdomain connects specific FD to
> STUBDOM_CONSOLE_RESTORE
> + */
> + flexarray_append(dm_args, "-incoming");
> + flexarray_append(dm_args, "fd:3");
Would it be possible to use a different fixed fd number ? Low numbers
are particularly vulnerable to clashes with autoallocated numbers.
I suggest randomly allocating one in the range [64,192>. My random
number generator picked 119. So 118 and 119 ?
Also, why couldn't your wrapper script add this argument ? If you do
that there then there is one place that knows the fd number and a
slightly less tortuous linkage between libxl and the script...
It's not stated anywhere here that I can see but I think what is
happening here is that your wrapper script knows the qemu savefile
pathname and reads it directly. Maybbe a comment would be
worthwhile ?
The code looks like a good implementation of what it does, though.
Regards,
Ian.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |