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

[Julien Grall <julien.grall@xxxxxxx>]

Hi Stefano,

On 31/05/16 10:21, Stefano Stabellini wrote:
> On Mon, 30 May 2016, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 30/05/2016 15:45, Stefano Stabellini wrote:
> > > On Mon, 23 May 2016, Julien Grall wrote:
> > > > Hi Stefano,
> > > >
> > > > On 21/05/16 16:09, Stefano Stabellini wrote:
> > > > > On Thu, 5 May 2016, Julien Grall wrote:
> > > > > > +void __init apply_alternatives_all(void)
> > > > > > +{
> > > > > > +    int ret;
> > > > > > +
> > > > > > +       /* better not try code patching on a live SMP system */
> > > > > > +    ret = stop_machine_run(__apply_alternatives_multi_stop, NULL,
> > > > > > NR_CPUS);
> > > > > Why not just call stop_machine_run, passing 0 as the cpu to run
> > > > > __apply_alternatives_multi_stop on? Given that you already have
> > > > > secondary cpus spinning in __apply_alternatives_multi_stop.  What am I
> > > > > missing?
> > > > Someone as to call __apply_alternatives_multi_stop on secondary CPUs.
> > > Why? Secondary cpus would be just left spinning at the beginning of the
> > > function. You might as well leave them spinning in
> > > stopmachine_wait_state.
> > Because, we may need to patch the stop_machine state machine (spinlock,...).
> > So the safest place whilst the code is patched is
> > __apply_alternatives_multi_stop.
> >
> > Note that there is a comment on top of __apply_alternatives_multi_stop to
> > explain the reason.
> Have you tried patching stop_machine? What if you need to patch
> __apply_alternatives_multi_stop? :-)
We have to define a safe place where the CPUs could spin. I.e the 
instructions will not be patched.
Whilst stop_machine may not be patched today, it is common code and we 
don't know how this will evolve in the future.
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).
Regards,

--
Julien Grall

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