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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Jun 02, 2016 at 04:14:04PM +0100, Julien Grall wrote:
> 
> 
> 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.

Oh, in that case please just mention that in the commit description.

> 
> Regards,
> 
> -- 
> Julien Grall

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