Re: [Xen-devel] [RFC 10/16] xen/arm: Introduce alternative runtime patching

[Julien Grall <julien.grall@xxxxxxx>]

On 02/06/16 16:04, Julien Grall wrote:
> Hi Konrad,
>
> On 02/06/16 15:46, Konrad Rzeszutek Wilk wrote:
> > On Tue, May 31, 2016 at 11:24:10AM +0100, Julien Grall wrote:
> > > On 31/05/16 10:21, Stefano Stabellini wrote:
> > > > On Mon, 30 May 2016, Julien Grall wrote:
> > > By spinning in __apply_alternatives_multi_stop we protect us against
> > > modification in the common code and tricky bug (yes it might be
> > > difficult to
> > > hit and debug).
> > I feel that you are moving down the stack to try to make the
> > impact of doing modifications have no impact (or as low as possible).
> >
> > And it would work now, but I am concerned that in the future it may be
> > not soo future proof.
> Can you detail here?
>
> > Would it perhaps make sense to make some of the livepatching mechanism
> > be exposed as general code? And use it for alternative asm as well?
> The code to sync the CPU looks very similar to stop_machine, so why
> would we want to get yet another mechanism to sync the CPUs and execute
> a specific function?
I forgot to mention that apply_alternatives_all is only called one time 
during the boot and before CPU0 goes in idle_loop. If we have to patch 
afterward, we would use apply_alternatives which consider that all the 
CPUs have been parked somewhere else.
Regards,

--
Julien Grall

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