From: Eduardo Habkost <ehabkost@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andrew Morton <akpm@osdl.org>,
kvm@vger.kernel.org, kexec@lists.infradead.org,
Haren Myneni <hbabu@us.ibm.com>,
Simon Horman <horms@verge.net.au>, Avi Kivity <avi@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH 0/2] kvm: disable virtualization on kdump
Date: Tue, 28 Oct 2008 17:45:30 -0200 [thread overview]
Message-ID: <20081028194530.GK23893@blackpad> (raw)
In-Reply-To: <m18wsa7xl0.fsf@frodo.ebiederm.org>
On Mon, Oct 27, 2008 at 10:32:43AM -0700, Eric W. Biederman wrote:
> Avi Kivity <avi@redhat.com> 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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2008-10-28 19:46 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-20 15:01 [PATCH 0/2] kvm: disable virtualization on kdump Eduardo Habkost
2008-10-20 15:01 ` [PATCH 1/2] kdump: crash-time CPU halt notifier interface Eduardo Habkost
2008-10-20 15:01 ` [PATCH 2/2] kvm: disable virtualization when halting CPUs on crash Eduardo Habkost
2008-10-22 23:28 ` [PATCH 0/2] kvm: disable virtualization on kdump Simon Horman
2008-10-23 19:41 ` Eduardo Habkost
2008-10-23 22:29 ` Simon Horman
2008-10-24 1:00 ` Eric W. Biederman
2008-10-26 12:49 ` Avi Kivity
2008-10-26 14:46 ` Eric W. Biederman
2008-10-26 15:07 ` Avi Kivity
2008-10-26 21:39 ` Eduardo Habkost
2008-10-27 2:08 ` Eric W. Biederman
2008-10-27 9:13 ` Avi Kivity
2008-10-27 12:28 ` Eduardo Habkost
2008-10-27 14:02 ` Avi Kivity
2008-10-27 17:32 ` Eric W. Biederman
2008-10-28 19:45 ` Eduardo Habkost [this message]
2008-10-28 20:13 ` Eric W. Biederman
2008-10-29 9:41 ` Avi Kivity
2008-10-29 14:54 ` Eric W. Biederman
2008-10-29 17:03 ` Avi Kivity
2008-10-30 1:33 ` Eric W. Biederman
2008-10-30 7:35 ` Chris Lalancette
2008-10-30 7:43 ` Avi Kivity
2008-10-30 7:52 ` Avi Kivity
2008-10-29 9:31 ` Avi Kivity
2008-10-27 15:05 ` Eric W. Biederman
2008-10-27 15:50 ` Eduardo Habkost
2008-10-27 8:54 ` Avi Kivity
2008-10-27 13:09 ` Vivek Goyal
2008-10-27 14:04 ` Avi Kivity
2008-10-29 20:10 ` Eduardo Habkost
2008-10-29 20:29 ` Avi Kivity
2008-10-29 21:05 ` Vivek Goyal
2008-10-30 0:58 ` Eric W. Biederman
2008-10-26 21:47 ` Eric W. Biederman
2008-10-27 8:59 ` Avi Kivity
2008-10-27 15:02 ` Eric W. Biederman
2008-10-27 15:38 ` Eduardo Habkost
2008-10-26 12:46 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081028194530.GK23893@blackpad \
--to=ehabkost@redhat.com \
--cc=akpm@osdl.org \
--cc=avi@redhat.com \
--cc=ebiederm@xmission.com \
--cc=hbabu@us.ibm.com \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=vgoyal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox