linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: andrew.cooper3@citrix.com, hpa@zytor.com, jbeulich@suse.com,
	konrad.wilk@oracle.com, mingo@redhat.com, tglx@linutronix.de,
	x86@kernel.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	xen-devel@lists.xensource.com
Subject: Re: [PATCH v2 01/11] kexec: introduce kexec_ops struct
Date: Tue, 20 Nov 2012 08:40:39 -0800	[thread overview]
Message-ID: <87lidwtego.fsf@xmission.com> (raw)
In-Reply-To: <1353423893-23125-2-git-send-email-daniel.kiper@oracle.com> (Daniel Kiper's message of "Tue, 20 Nov 2012 16:04:43 +0100")

Daniel Kiper <daniel.kiper@oracle.com> writes:

> Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default
> functions or require some changes in behavior of kexec/kdump generic code.
> To cope with that problem kexec_ops struct was introduced. It allows
> a developer to replace all or some functions and control some
> functionality of kexec/kdump generic code.
>
> Default behavior of kexec/kdump generic code is not changed.

Ick.

> v2 - suggestions/fixes:
>    - add comment for kexec_ops.crash_alloc_temp_store member
>      (suggested by Konrad Rzeszutek Wilk),
>    - simplify kexec_ops usage
>      (suggested by Konrad Rzeszutek Wilk).
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  include/linux/kexec.h |   26 ++++++++++
>  kernel/kexec.c        |  131 +++++++++++++++++++++++++++++++++++++------------
>  2 files changed, 125 insertions(+), 32 deletions(-)
>
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index d0b8458..c8d0b35 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -116,7 +116,33 @@ struct kimage {
>  #endif
>  };
>  
> +struct kexec_ops {
> +	/*
> +	 * Some kdump implementations (e.g. Xen PVOPS dom0) could not access
> +	 * directly crash kernel memory area. In this situation they must
> +	 * allocate memory outside of it and later move contents from temporary
> +	 * storage to final resting places (usualy done by relocate_kernel()).
> +	 * Such behavior could be enforced by setting
> +	 * crash_alloc_temp_store member to true.
> +	 */

Why in the world would Xen not be able to access crash kernel memory?
As currently defined it is normal memory that the kernel chooses not to
use.

If relocate kernel can access that memory you definitely can access the
memory so the comment does not make any sense.

> +	bool crash_alloc_temp_store;
> +	struct page *(*kimage_alloc_pages)(gfp_t gfp_mask,
> +						unsigned int order,
> +						unsigned long limit);
> +	void (*kimage_free_pages)(struct page *page);
> +	unsigned long (*page_to_pfn)(struct page *page);
> +	struct page *(*pfn_to_page)(unsigned long pfn);
> +	unsigned long (*virt_to_phys)(volatile void *address);
> +	void *(*phys_to_virt)(unsigned long address);
> +	int (*machine_kexec_prepare)(struct kimage *image);
> +	int (*machine_kexec_load)(struct kimage *image);
> +	void (*machine_kexec_cleanup)(struct kimage *image);
> +	void (*machine_kexec_unload)(struct kimage *image);
> +	void (*machine_kexec_shutdown)(void);
> +	void (*machine_kexec)(struct kimage *image);
> +};

Ugh.  This is a nasty abstraction.

You are mixing and matching a bunch of things together here.

If you need to override machine_kexec_xxx please do that on a per
architecture basis.

Special case overrides of page_to_pfn, pfn_to_page, virt_to_phys,
phys_to_virt, and friends seem completely inappropriate.

There may be a point to all of these but you are mixing and matching
things badly.


Eric

  parent reply	other threads:[~2012-11-20 16:41 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   ` Eric W. Biederman [this message]
2012-11-21 10:52     ` [PATCH v2 01/11] kexec: introduce kexec_ops struct 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
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=87lidwtego.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=daniel.kiper@oracle.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=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).