On Mon, Nov 26, 2012 at 11:43:10AM -0600, Eric W. Biederman wrote: > Gleb Natapov <gleb at redhat.com> writes: > > > On Mon, Nov 26, 2012 at 09:08:54AM -0600, Eric W. Biederman wrote: > >> Zhang Yanfei <zhangyanfei at cn.fujitsu.com> writes: > >> > >> > This patch adds an atomic notifier list named crash_notifier_list. > >> > Currently, when loading kvm-intel module, a notifier will be registered > >> > in the list to enable vmcss loaded on all cpus to be VMCLEAR'd if > >> > needed. > >> > >> crash_notifier_list ick gag please no. Effectively this makes the kexec > >> on panic code path undebuggable. > >> > >> Instead we need to use direct function calls to whatever you are doing. > >> > > The code walks linked list in kvm-intel module and calls vmclear on > > whatever it finds there. Since the function have to resides in kvm-intel > > module it cannot be called directly. Is callback pointer that is set > > by kvm-intel more acceptable? > > Yes a specific callback function is more acceptable. Looking a little > deeper vmclear_local_loaded_vmcss is not particularly acceptable. It is > doing a lot of work that is unnecessary to save the virtual registers > on the kexec on panic path. > What work are you referring to in particular that may not be acceptable? > In fact I wonder if it might not just be easier to call vmcs_clear to a > fixed per cpu buffer. > There may be more than one vmcs loaded on a cpu, hence the list. > Performing list walking in interrupt context without locking in > vmclear_local_loaded vmcss looks a bit scary. Not that locking would > make it any better, as locking would simply add one more way to deadlock > the system. Only an rcu list walk is at all safe. A list walk that > modifies the list as vmclear_local_loaded_vmcss does is definitely not safe. > The list vmclear_local_loaded walks is per cpu. Zhang's kvm patch disables kexec callback while list is modified. -- Gleb.
