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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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? :-)

I'll refer to Konrad on whether this is a good approach or not.

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