[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a41a685e-7953-0b63-4c85-7af8e346bd02@suse.com>
Date: Wed, 25 Apr 2018 14:53:08 +0200
From: Juergen Gross <jgross@...e.com>
To: Petr Tesarik <ptesarik@...e.cz>, x86@...nel.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Tom Lendacky <thomas.lendacky@....com>,
Borislav Petkov <bp@...e.de>,
Andy Lutomirski <luto@...nel.org>,
Mikulas Patocka <mpatocka@...hat.com>,
Jean Delvare <jdelvare@...e.de>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Dou Liyang <douly.fnst@...fujitsu.com>
Cc: xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: Do not reserve a crash kernel region if booted on
Xen PV
On 25/04/18 12:08, Petr Tesarik wrote:
> Xen PV domains cannot shut down and start a crash kernel. Instead,
> the crashing kernel makes a SCHEDOP_shutdown hypercall with the
> reason code SHUTDOWN_crash, cf. xen_crash_shutdown() machine op in
> arch/x86/xen/enlighten_pv.c.
>
> A crash kernel reservation is merely a waste of RAM in this case. It
> may also confuse users of kexec_load(2) and/or kexec_file_load(2).
> When flags include KEXEC_ON_CRASH or KEXEC_FILE_ON_CRASH,
> respectively, these syscalls return success, which is technically
> correct, but the crash kexec image will never be actually used.
>
> Signed-off-by: Petr Tesarik <ptesarik@...e.com>
Reviewed-by: Juergen Gross <jgross@...e.com>
Juergen
Powered by blists - more mailing lists