Re: [PATCH 0/2] kvm: disable virtualization on kdump

[Eduardo Habkost <ehabkost-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Mon, Oct 27, 2008 at 10:32:43AM -0700, Eric W. Biederman wrote:
> Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
<snip>
> >
> > I wouldn't mind notifiers (with a nice comment explaining that you must know
> > what you're doing, though that's the case with most kernel APIs).  I'm fine with
> > either approach.
> 
> This is the 3rd request I have seen for a notifier.  This is the first
> request I have seen for code that must be executed in the kexec on
> panic path.  So history suggest to me that notifiers make it
> unreasonably easy to get code onto the kexec on panic code path.
> 
> Occasionally the kexec on panic code path is tested to see how
> well it works in strange situations like being called from
> a stack overflow etc.
> 
> The rest of the history is that previous attempts like lkcd
> had very programmer friendly interfaces, that worked fine
> in test environments giving beautiful core dumps, but when things
> broke in the field they were essentially useless.  The kdump
> approach is still not completely reliable but it does work
> well enough that people get useful crash dumps sometimes.
> 
> I feel anything that makes the kexec on panic code path harder
> to verify it will work when things are crazy broken, like
> a notifier is something we should avoid.

I am still wondering if a simple function pointer (instead of a full
notifier interface) would be good enough. It looks like a reasonable
tradeoff.

I think I will get flamed if I try to pull to the core a bunch of code
that always lived in the KVM module.  8)

And even if we pull those functions to the core, we will still have
a function pointer on the new code anyway, because we would need to
support vmx and svm.

-- 
Eduardo