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

[Julien Grall <julien.grall@xxxxxxx>]

Hi Konrad,

On 06/06/16 15:17, Konrad Rzeszutek Wilk wrote:
> 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.
Will do in the next version.

Cheers,

--
Julien Grall

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