On Thu, Jun 02, 2016 at 04:14:04PM +0100, Julien Grall wrote: > > > On 02/06/16 16:04, Julien Grall wrote: > >Hi Konrad, > > > >On 02/06/16 15:46, Konrad Rzeszutek Wilk wrote: > >>On Tue, May 31, 2016 at 11:24:10AM +0100, Julien Grall wrote: > >>>On 31/05/16 10:21, Stefano Stabellini wrote: > >>>>On Mon, 30 May 2016, Julien Grall wrote: > >>>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). > >> > >>I feel that you are moving down the stack to try to make the > >>impact of doing modifications have no impact (or as low as possible). > >> > >>And it would work now, but I am concerned that in the future it may be > >>not soo future proof. > > > >Can you detail here? > > > >>Would it perhaps make sense to make some of the livepatching mechanism > >>be exposed as general code? And use it for alternative asm as well? > > > >The code to sync the CPU looks very similar to stop_machine, so why > >would we want to get yet another mechanism to sync the CPUs and execute > >a specific function? > > I forgot to mention that apply_alternatives_all is only called one time > during the boot and before CPU0 goes in idle_loop. If we have to patch > afterward, we would use apply_alternatives which consider that all the CPUs > have been parked somewhere else.
Oh, in that case please just mention that in the commit description. > > Regards, > > -- > Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
