Re: [PATCH v1 1/5] xsplice: Design document.

[Ross Lagerwall <ross.lagerwall@citrix.com>]

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