[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] tools/many: Fix Generation ID restore interface.



On 11/25/2013 08:40 PM, Andrew Cooper wrote:
The original Generation ID code was submitted before the specification had
been finalised, and changed completely between the final draft and formal
release.

Most notably, the size of the Generation ID has doubled to 128 bits, and
changing it now involves writing a new cryptographically random number in the
appropriate location, rather than simply incrementing it.

The xc_domain_save() side of the code is fine, but the xc_domain_restore()
needs substantial changes to be usable.

This patch replaces the old xc_domain_restore() parameters with a new optional
restore_callback.  If the callback is provided, and an appropriate hunk is
found in the migration stream, the appropriate piece of guest memory is mapped
and provided to the callback.

This patch also fixes all the in-tree callers of xc_domain_restore().  All
callers had the functionality disabled, and never exposed in a public way.

Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
CC: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
CC: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
CC: George Dunlap <george.dunlap@xxxxxxxxxxxxx>

---

George:

   Despite this being a feature, I am requesting a freeze exemption.  It is
   functionality which was not used (or indeed useful) before, and remains that
   way as far as in-tree consumers are concerned.

   However, as there has been once recent xc_domain_restore() API change, it is
   less disruptive to other users to do another API change before the 4.4
   release rather than afterwards.

1. What is the value of this feature?

It's not used and not useful, so as far as I can tell, the value is 0. xc_domain_restore() is not a stable interface, so changing it isn't a consideration.

2. What is the risk of bugs that may slip the release? That may not be found and ship in the release?

It looks fairly straightforward, but the code it's modifying is incredibly fragile, and has a lot of potential combinations which are hard to test.

0 value + non-zero risk => I don't see a reason to accept it.

 -George


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


 


Rackspace

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