On 09/16/2015 10:01 PM, Konrad Rzeszutek Wilk wrote:
+### xSplice interdependencies
+
+xSplice patches interdependencies are tricky.
+
+There are the ways this can be addressed:
+ * A single large patch that subsumes and replaces all previous ones.
+ Over the life-time of patching the hypervisor this large patch
+ grows to accumulate all the code changes.
+ * Hotpatch stack - where an mechanism exists that loads the hotpatches
+ in the same order they were built in. We would need an build-id
+ of the hypevisor to make sure the hot-patches are build against the
+ correct build.
+ * Payload containing the old code to check against that. That allows
+ the hotpatches to be loaded indepedently (if they don't overlap) - or
+ if the old code also containst previously patched code - even if they
+ overlap.
+
+The disadvantage of the first large patch is that it can grow over
+time and not provide an bisection mechanism to identify faulty patches.
+
+The hot-patch stack puts stricts requirements on the order of the patches
+being loaded and requires an hypervisor build-id to match against.
+
+The old code allows much more flexibility and an additional guard,
+but is more complex to implement.
+
If the single large patch mechanism is used, a new REPLACE action is
needed to atomically replace one patch with another to prevent a window
where the hypervisor is unpatched. kpatch has a "replace" command for
this purpose. This may be useful even for the other mechanisms listed above.
From what I can tell:
* kSplice uses old code checking (method [3] above), although in
practice the userspace tools implement dependency logic to enforce a
linear stack of patches.
* kPatch and kGraft recommend using the single large patch mechanism
although there's nothing preventing two independent patches from being
loaded.
--
Ross Lagerwall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
