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

[Julien Grall <julien.grall@xxxxxxx>]

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.
Regards,

--
Julien Grall

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