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@lists.xen.org
http://lists.xen.org/xen-devel
