mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 10:11:27 +01:00
Pawel Wieczorkiewicz
8313c864fa
This is an implementation of 4 new livepatch module vetoing hooks, that can be optionally supplied along with modules. Hooks that currently exists in the livepatch mechanism aren't agile enough and have various limitations: * run only from within a quiescing zone * cannot conditionally prevent applying or reverting * do not have access to the module context To address these limitations the following has been implemented: 1) pre-apply hook runs before the apply action is scheduled for execution. Its main purpose is to prevent from applying a livepatch when certain expected conditions aren't met or when mutating actions implemented in the hook fail or cannot be executed. 2) post-apply hook runs after the apply action has been executed and quiescing zone exited. Its main purpose is to provide an ability to follow-up on actions performed by the pre- hook, when module application was successful or undo certain preparation steps of the pre- hook in case of a failure. The success/failure error code is provided to the post- hooks via the rc field of the payload structure. 3) pre-revert hook runs before the revert action is scheduled for execution. Its main purpose is to prevent from reverting a livepatch when certain expected conditions aren't met or when mutating actions implemented in the hook fail or cannot be executed. 4) post-revert hook runs after the revert action has been executed and quiescing zone exited. Its main purpose is to perform cleanup of all previously executed mutating actions in order to restore the original system state from before the current module application. The success/failure error code is provided to the post- hooks via the rc field of the payload structure. The replace action performs atomically the following actions: - revert all applied modules - apply a single replacement module. With the vetoing hooks in place various inter-hook dependencies may arise. Also, during the revert part of the operation certain vetoing hooks may detect failing conditions that previously were satisfied. That could in turn lead to situation when the revert part must be rolled back with all the pre- and post- hooks re-applied, which again can't be guaranteed to always succeed. The simplest response to this complication is to disallow the replace action completely on modules with vetoing hooks. Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de> Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com> Reviewed-by: Petre Eftime <epetre@amazon.com> Reviewed-by: Martin Pohlack <mpohlack@amazon.de> Reviewed-by: Norbert Manthey <nmanthey@amazon.de> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Sphinx documentation:
All source rendered by Sphinx is licensed under CC-BY-4.0.
You are free to:
Share:
Copy and redistribute the material in any medium or format.
Adapt:
Remix, transform, and build upon the material for any purpose, even
commercially.
Under the following terms:
Attribution:
You must give appropriate credit, provide a link to the license, and
indicate if changes were made. You may do so in any reasonable manner, but
not in any way that suggests the licensor endorses you or your use.
No additional restrictions:
You may not apply legal terms or technological measures that legally
restrict others from doing anything the license permits.
See https://creativecommons.org/licenses/by/4.0/ for full details.
This includes:
* All ReStructured Text files: docs/*/*.rst
* The Sphinx configuration file: docs/conf.py
* Content in Sphinx-exclusive subdirs: docs/*-guide/*
Other documentation:
There are a variety of text documents in various formats. These, given no
explicit license guidance, fall under Xen's default GPL-2.0 license.