[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.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.