From: Daniel Kiper <daniel.kiper@oracle.com>
To: <ebiederm@xmission.com>
Cc: <kexec@lists.infradead.org>, <xen-devel@lists.xensource.com>,
<konrad.wilk@oracle.com>, <tglx@linutronix.de>,
<maxim.uvarov@oracle.com>, <andrew.cooper3@citrix.com>,
<hpa@zytor.com>, <jbeulich@suse.com>, <mingo@redhat.com>,
<x86@kernel.org>, <virtualization@lists.linux-foundation.org>,
<vgoyal@redhat.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 01/11] kexec: introduce kexec firmware support
Date: Thu, 27 Dec 2012 16:18:56 -0800 (PST) [thread overview]
Message-ID: <2f3acfe3-c608-43d8-b76a-6ba69a872692@default> (raw)
> Daniel Kiper <daniel.kiper@oracle.com> writes:
>
> > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default
> > Linux infrastructure and require some support from firmware and/or hypervisor.
> > To cope with that problem kexec firmware infrastructure was introduced.
> > It allows a developer to use all kexec/kdump features of given firmware
> > or hypervisor.
>
> As this stands this patch is wrong.
>
> You need to pass an additional flag from userspace through /sbin/kexec
> that says load the kexec image in the firmware. A global variable here
> is not ok.
>
> As I understand it you are loading a kexec on xen panic image. Which
> is semantically different from a kexec on linux panic image. It is not
> ok to do have a silly global variable kexec_use_firmware.
Earlier we agreed that /sbin/kexec should call kexec syscall with
special flag. However, during work on Xen kexec/kdump v3 patch
I stated that this is insufficient because e.g. crash_kexec()
should execute different code in case of use of firmware support too.
Sadly syscall does not save this flag anywhere. Additionally, I stated
that kernel itself has the best knowledge which code path should be
used (firmware or plain Linux). If this decision will be left to userspace
then simple kexec syscall could crash system at worst case (e.g. when
plain Linux kexec will be used in case when firmware kaxec should be used).
However, if you wish I could add this flag to syscall. Additionally, I could
add function which enables firmware support and then kexec_use_firmware
variable will be global only in kexec.c module.
> Furthermore it is not ok to have a conditional
> code outside of header files.
I agree but how to dispatch execution e.g. in crash_kexec()
if we would like (I suppose) compile kexec firmware
support conditionally?
Daniel
next reply other threads:[~2012-12-28 0:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-28 0:18 Daniel Kiper [this message]
2012-12-28 3:06 ` Eric W. Biederman
2013-01-04 14:04 ` Daniel Kiper
-- strict thread matches above, loose matches on Subject: below --
2012-12-27 2:18 [PATCH v3 00/11] xen: Initial kexec/kdump implementation Daniel Kiper
2012-12-27 2:18 ` [PATCH v3 01/11] kexec: introduce kexec firmware support Daniel Kiper
2012-12-27 4:46 ` Eric W. Biederman
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=2f3acfe3-c608-43d8-b76a-6ba69a872692@default \
--to=daniel.kiper@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=jbeulich@suse.com \
--cc=kexec@lists.infradead.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maxim.uvarov@oracle.com \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xensource.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
all inboxes | Powered by JetHome®