[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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,

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

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

Because, we may need to patch the stop_machine state machine (spinlock,...).
So the safest place whilst the code is patched is

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).


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.