On 9/28/19 4:12 PM, Pawel Wieczorkiewicz wrote: > 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 <wipa...@amazon.de> > Reviewed-by: Andra-Irina Paraschiv <andra...@amazon.com> > Reviewed-by: Petre Eftime <epe...@amazon.com> > Reviewed-by: Martin Pohlack <mpohl...@amazon.de> > Reviewed-by: Norbert Manthey <nmant...@amazon.de> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Reviewed-by: Ross Lagerwall <ross.lagerw...@citrix.com>
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
