From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"H. Peter Anvin" <hpa@zytor.com>
Cc: "x86@kernel.org" <x86@kernel.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Daniel Kiper" <daniel.kiper@oracle.com>,
"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH v2 01/11] kexec: introduce kexec_ops struct
Date: Fri, 23 Nov 2012 09:53:37 +0000 [thread overview]
Message-ID: <50AF55B102000078000AABF3@nat28.tlf.novell.com> (raw)
In-Reply-To: <50AED7B8.7040902@citrix.com>
>>> On 23.11.12 at 02:56, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 23/11/2012 01:38, H. Peter Anvin wrote:
>> I still don't really get why it can't be isolated from dom0, which would
> make more sense to me, even for a Xen crash.
>>
>
> The crash region (as specified by crashkernel= on the Xen command line)
> is isolated from dom0.
>
> dom0 (using the kexec utility etc) has the task of locating the Xen
> crash notes (using the kexec hypercall interface), constructing a binary
> blob containing kernel, initram and gubbins, and asking Xen to put this
> blob in the crash region (again, using the kexec hypercall interface).
>
> I do not see how this is very much different from the native case
> currently (although please correct me if I am misinformed). Linux has
> extra work to do by populating /proc/iomem with the Xen crash regions
> boot (so the kexec utility can reference their physical addresses when
> constructing the blob), and should just act as a conduit between the
> kexec system call and the kexec hypercall to load the blob.
But all of this _could_ be done completely independent of the
Dom0 kernel's kexec infrastructure (i.e. fully from user space,
invoking the necessary hypercalls through the privcmd driver).
It's just that parts of the kexec infrastructure can be re-used
(and hence that mechanism probably seemed the easier approach
to the implementer of the original kexec-on-Xen). If the kernel
folks dislike that re-use (quite understandably looking at how
much of it needs to be re-done), that shouldn't prevent us from
looking into the existing alternatives.
Jan
next prev parent reply other threads:[~2012-11-23 9:52 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-20 15:04 [PATCH v2 00/11] xen: Initial kexec/kdump implementation Daniel Kiper
2012-11-20 15:04 ` [PATCH v2 01/11] kexec: introduce kexec_ops struct Daniel Kiper
2012-11-20 15:04 ` [PATCH v2 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE Daniel Kiper
2012-11-20 15:04 ` [PATCH v2 03/11] xen: Introduce architecture independent data for kexec/kdump Daniel Kiper
2012-11-20 15:04 ` [PATCH v2 04/11] x86/xen: Introduce architecture dependent " Daniel Kiper
2012-11-20 15:04 ` [PATCH v2 05/11] x86/xen: Register resources required by kexec-tools Daniel Kiper
2012-11-20 15:04 ` [PATCH v2 06/11] x86/xen: Add i386 kexec/kdump implementation Daniel Kiper
2012-11-20 15:04 ` [PATCH v2 07/11] x86/xen: Add x86_64 " Daniel Kiper
2012-11-20 15:04 ` [PATCH v2 08/11] x86/xen: Add kexec/kdump makefile rules Daniel Kiper
2012-11-20 15:04 ` [PATCH v2 09/11] x86/xen/enlighten: Add init and crash kexec/kdump hooks Daniel Kiper
2012-11-20 15:04 ` [PATCH v2 10/11] drivers/xen: Export vmcoreinfo through sysfs Daniel Kiper
2012-11-20 15:04 ` [PATCH v2 11/11] x86: Add Xen kexec control code size check to linker script Daniel Kiper
2012-11-20 15:52 ` [PATCH v2 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE Jan Beulich
2012-11-20 16:40 ` [PATCH v2 01/11] kexec: introduce kexec_ops struct Eric W. Biederman
2012-11-21 10:52 ` Daniel Kiper
2012-11-22 12:15 ` Eric W. Biederman
2012-11-22 17:37 ` H. Peter Anvin
2012-11-23 9:56 ` Jan Beulich
2012-11-23 10:53 ` [Xen-devel] " Ian Campbell
2012-11-22 17:47 ` H. Peter Anvin
2012-11-22 18:07 ` Andrew Cooper
2012-11-22 22:26 ` H. Peter Anvin
2014-03-31 10:50 ` Petr Tesarik
2012-11-23 0:12 ` Andrew Cooper
2012-11-23 1:34 ` H. Peter Anvin
2012-11-23 1:38 ` H. Peter Anvin
2012-11-23 1:56 ` Andrew Cooper
2012-11-23 9:53 ` Jan Beulich [this message]
2012-11-23 10:37 ` Daniel Kiper
2012-11-23 10:51 ` [Xen-devel] " Ian Campbell
2012-11-23 11:13 ` Daniel Kiper
2012-11-23 10:51 ` Jan Beulich
2012-11-23 11:08 ` Daniel Kiper
2012-11-23 9:47 ` Daniel Kiper
2012-11-23 20:24 ` 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=50AF55B102000078000AABF3@nat28.tlf.novell.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=daniel.kiper@oracle.com \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--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;
as well as URLs for NNTP newsgroup(s).