From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Borislav Petkov <bp@alien8.de>,
Andy Lutomirski <luto@kernel.org>,
Sean Christopherson <seanjc@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Joerg Roedel <jroedel@suse.de>,
Ard Biesheuvel <ardb@kernel.org>,
Andi Kleen <ak@linux.intel.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
David Rientjes <rientjes@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
Tom Lendacky <thomas.lendacky@amd.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Ingo Molnar <mingo@redhat.com>,
Varad Gautam <varad.gautam@suse.com>,
Dario Faggioli <dfaggioli@suse.com>,
Mike Rapoport <rppt@kernel.org>,
David Hildenbrand <david@redhat.com>,
marcelo.cerri@canonical.com, tim.gardner@canonical.com,
khalid.elmously@canonical.com, philip.cox@canonical.com,
x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev,
linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
kexec@lists.infradead.org
Subject: Re: [PATCHv7 11/14] x86: Disable kexec if system has unaccepted memory
Date: Thu, 23 Jun 2022 16:48:59 -0500 [thread overview]
Message-ID: <87a6a3aw50.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <6be29d38-5c93-7cc9-0de7-235d3f83773c@intel.com> (Dave Hansen's message of "Thu, 23 Jun 2022 10:23:59 -0700")
Dave Hansen <dave.hansen@intel.com> writes:
> ... adding kexec folks
>
> On 6/14/22 05:02, Kirill A. Shutemov wrote:
>> On kexec, the target kernel has to know what memory has been accepted.
>> Information in EFI map is out of date and cannot be used.
>>
>> boot_params.unaccepted_memory can be used to pass the bitmap between two
>> kernels on kexec, but the use-case is not yet implemented.
>>
>> Disable kexec on machines with unaccepted memory for now.
> ...
>> +static int __init unaccepted_init(void)
>> +{
>> + if (!boot_params.unaccepted_memory)
>> + return 0;
>> +
>> +#ifdef CONFIG_KEXEC_CORE
>> + /*
>> + * TODO: Information on memory acceptance status has to be communicated
>> + * between kernel.
>> + */
>> + pr_warn("Disable kexec: not yet supported on systems with unaccepted memory\n");
>> + kexec_load_disabled = 1;
>> +#endif
>
> This looks to be the *only* in-kernel user tweaking kexec_load_disabled.
> It doesn't feel great to just be disabling kexec like this. Why not
> just fix it properly?
>
> What do the kexec folks think?
I didn't realized someone had implemented kexec_load_disabled. I am not
particularly happy about that. It looks like an over-broad stick that
we will have to support forever.
This change looks like it just builds on that bad decision.
If people don't want to deal with this situation right now, then I
recommend they make this new code and KEXEC conflict at the Kconfig
level. That would give serious incentive to adding the missing
implementation.
If there is some deep and fundamental why this can not be supported
then it probably makes sense to put some code in the arch_kexec_load
hook that verifies that deep and fundamental reason is present.
With the kexec code all we have to verify it works is a little testing
and careful code review. Something like this makes code review much
harder because the entire kernel has to be checked to see if some random
driver without locking changed a variable. Rather than having it
apparent that this special case exists when reading through the kexec
code.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2022-06-23 21:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220614120231.48165-1-kirill.shutemov@linux.intel.com>
[not found] ` <20220614120231.48165-12-kirill.shutemov@linux.intel.com>
2022-06-23 17:23 ` [PATCHv7 11/14] x86: Disable kexec if system has unaccepted memory Dave Hansen
2022-06-23 21:48 ` Eric W. Biederman [this message]
2022-06-24 2:00 ` Kirill A. Shutemov
2022-06-28 23:51 ` Kirill A. Shutemov
2022-06-29 0:10 ` Dave Hansen
2022-06-29 0:59 ` Kirill A. Shutemov
2022-07-04 7:18 ` Dave Young
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=87a6a3aw50.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=david@redhat.com \
--cc=dfaggioli@suse.com \
--cc=jroedel@suse.de \
--cc=kexec@lists.infradead.org \
--cc=khalid.elmously@canonical.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=marcelo.cerri@canonical.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=philip.cox@canonical.com \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tim.gardner@canonical.com \
--cc=varad.gautam@suse.com \
--cc=vbabka@suse.cz \
--cc=x86@kernel.org \
/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