From: Baoquan He <bhe@redhat.com>
To: "Huang, Kai" <kai.huang@intel.com>,
Nikolay Borisov <nik.borisov@suse.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
"Hunter, Adrian" <adrian.hunter@intel.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
"Reshetova, Elena" <elena.reshetova@intel.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>,
"Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
"Kalra, Ashish" <ashish.kalra@amd.com>,
Sean Christopherson <seanjc@google.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv6 00/16] x86/tdx: Add kexec support
Date: Wed, 31 Jan 2024 23:23:50 +0800 [thread overview]
Message-ID: <ZbpmBulaR7eft/CE@MiWiFi-R3L-srv> (raw)
In-Reply-To: <BL1PR11MB5978633DF36A69F8020818E1F77C2@BL1PR11MB5978.namprd11.prod.outlook.com>
On 01/31/24 at 01:07pm, Huang, Kai wrote:
> > > Runtime disabling kexec looks better than at cmpile time, esp for
> > > distros. While from above patch, making using of kexec_load_disabled
> > > to achive the runtime disabling may not be so good. Because we have a
> > > front door to enable it through:
> > >
> > > /proc/sys/kernel/kexec_load_disabled
> >
> > AFAIU it can't be enabled via this sysctl because the handler for it expects
> > only 1 to be written to it:
> >
> > 2 .proc_handler = proc_dointvec_minmax,
> >
> > 1 .extra1 = SYSCTL_ONE,
> >
> > 994 .extra2 = SYSCTL_ONE,
> >
>
> This is also my understanding.
>
> The documentation also says once it is turned to disable we cannot turn back again:
>
> kexec_load_disable
> ===================
>
> A toggle indicating if the syscalls ``kexec_load`` and
> ``kexec_file_load`` have been disabled.
> This value defaults to 0 (false: ``kexec_*load`` enabled), but can be
> set to 1 (true: ``kexec_*load`` disabled).
> Once true, kexec can no longer be used, and the toggle cannot be set
> back to false.
you are quite right, I have never noticed this, thanks.
Then then mentioned patch looks good to me.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: "Huang, Kai" <kai.huang@intel.com>,
Nikolay Borisov <nik.borisov@suse.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
"Hunter, Adrian" <adrian.hunter@intel.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
"Reshetova, Elena" <elena.reshetova@intel.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>,
"Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
"Kalra, Ashish" <ashish.kalra@amd.com>,
Sean Christopherson <seanjc@google.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv6 00/16] x86/tdx: Add kexec support
Date: Wed, 31 Jan 2024 23:23:50 +0800 [thread overview]
Message-ID: <ZbpmBulaR7eft/CE@MiWiFi-R3L-srv> (raw)
In-Reply-To: <BL1PR11MB5978633DF36A69F8020818E1F77C2@BL1PR11MB5978.namprd11.prod.outlook.com>
On 01/31/24 at 01:07pm, Huang, Kai wrote:
> > > Runtime disabling kexec looks better than at cmpile time, esp for
> > > distros. While from above patch, making using of kexec_load_disabled
> > > to achive the runtime disabling may not be so good. Because we have a
> > > front door to enable it through:
> > >
> > > /proc/sys/kernel/kexec_load_disabled
> >
> > AFAIU it can't be enabled via this sysctl because the handler for it expects
> > only 1 to be written to it:
> >
> > 2 .proc_handler = proc_dointvec_minmax,
> >
> > 1 .extra1 = SYSCTL_ONE,
> >
> > 994 .extra2 = SYSCTL_ONE,
> >
>
> This is also my understanding.
>
> The documentation also says once it is turned to disable we cannot turn back again:
>
> kexec_load_disable
> ===================
>
> A toggle indicating if the syscalls ``kexec_load`` and
> ``kexec_file_load`` have been disabled.
> This value defaults to 0 (false: ``kexec_*load`` enabled), but can be
> set to 1 (true: ``kexec_*load`` disabled).
> Once true, kexec can no longer be used, and the toggle cannot be set
> back to false.
you are quite right, I have never noticed this, thanks.
Then then mentioned patch looks good to me.
next prev parent reply other threads:[~2024-01-31 15:24 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 12:55 [PATCHv6 00/16] x86/tdx: Add kexec support Kirill A. Shutemov
2024-01-24 12:55 ` [PATCHv6 01/16] x86/acpi: Extract ACPI MADT wakeup code into a separate file Kirill A. Shutemov
2024-01-24 12:55 ` [PATCHv6 02/16] x86/apic: Mark acpi_mp_wake_* variables as __ro_after_init Kirill A. Shutemov
2024-01-24 12:55 ` [PATCHv6 03/16] cpu/hotplug: Add support for declaring CPU offlining not supported Kirill A. Shutemov
2024-01-24 12:55 ` [PATCHv6 04/16] cpu/hotplug, x86/acpi: Disable CPU offlining for ACPI MADT wakeup Kirill A. Shutemov
2024-01-24 12:55 ` [PATCHv6 05/16] x86/kexec: Keep CR4.MCE set during kexec for TDX guest Kirill A. Shutemov
2024-01-24 12:55 ` [PATCHv6 06/16] x86/mm: Make x86_platform.guest.enc_status_change_*() return errno Kirill A. Shutemov
2024-01-24 12:55 ` [PATCHv6 07/16] x86/mm: Return correct level from lookup_address() if pte is none Kirill A. Shutemov
2024-01-24 12:55 ` [PATCHv6 08/16] x86/tdx: Account shared memory Kirill A. Shutemov
2024-01-24 12:55 ` [PATCHv6 09/16] x86/mm: Adding callbacks to prepare encrypted memory for kexec Kirill A. Shutemov
2024-01-29 7:22 ` Nikolay Borisov
2024-01-29 7:22 ` Nikolay Borisov
2024-01-24 12:55 ` [PATCHv6 10/16] x86/tdx: Convert shared memory back to private on kexec Kirill A. Shutemov
2024-01-29 10:24 ` Kalra, Ashish
2024-01-29 10:24 ` Kalra, Ashish
2024-01-29 10:36 ` Kirill A. Shutemov
2024-01-29 10:36 ` Kirill A. Shutemov
2024-01-29 13:09 ` Kalra, Ashish
2024-01-29 13:09 ` Kalra, Ashish
2024-01-29 13:34 ` Kirill A. Shutemov
2024-01-29 13:34 ` Kirill A. Shutemov
2024-01-24 12:55 ` [PATCHv6 11/16] x86/mm: Make e820_end_ram_pfn() cover E820_TYPE_ACPI ranges Kirill A. Shutemov
2024-01-24 12:55 ` [PATCHv6 12/16] x86/acpi: Rename fields in acpi_madt_multiproc_wakeup structure Kirill A. Shutemov
2024-01-24 12:55 ` [PATCHv6 13/16] x86/acpi: Do not attempt to bring up secondary CPUs in kexec case Kirill A. Shutemov
2024-01-24 12:55 ` [PATCHv6 14/16] x86/smp: Add smp_ops.stop_this_cpu() callback Kirill A. Shutemov
2024-01-26 14:08 ` Huang, Kai
2024-01-26 14:08 ` Huang, Kai
2024-01-24 12:55 ` [PATCHv6 15/16] x86/mm: Introduce kernel_ident_mapping_free() Kirill A. Shutemov
2024-01-26 14:10 ` Huang, Kai
2024-01-26 14:10 ` Huang, Kai
2024-01-24 12:55 ` [PATCHv6 16/16] x86/acpi: Add support for CPU offlining for ACPI MADT wakeup method Kirill A. Shutemov
2024-01-26 14:21 ` Huang, Kai
2024-01-26 14:21 ` Huang, Kai
2024-01-27 18:15 ` kirill.shutemov
2024-01-27 18:15 ` kirill.shutemov
2024-01-26 20:03 ` Kuppuswamy Sathyanarayanan
2024-01-26 20:03 ` Kuppuswamy Sathyanarayanan
2024-01-27 19:35 ` Kirill A. Shutemov
2024-01-27 19:35 ` Kirill A. Shutemov
2024-01-30 13:43 ` [PATCHv6 00/16] x86/tdx: Add kexec support Paolo Bonzini
2024-01-30 13:43 ` Paolo Bonzini
2024-01-30 13:55 ` Kirill A. Shutemov
2024-01-30 13:55 ` Kirill A. Shutemov
2024-01-30 14:59 ` Paolo Bonzini
2024-01-30 14:59 ` Paolo Bonzini
2024-01-30 15:15 ` Kirill A. Shutemov
2024-01-30 15:15 ` Kirill A. Shutemov
2024-01-30 14:04 ` Huang, Kai
2024-01-30 14:04 ` Huang, Kai
2024-01-31 7:31 ` Nikolay Borisov
2024-01-31 7:31 ` Nikolay Borisov
2024-01-31 12:47 ` Baoquan He
2024-01-31 12:47 ` Baoquan He
2024-01-31 12:58 ` Nikolay Borisov
2024-01-31 12:58 ` Nikolay Borisov
2024-01-31 13:07 ` Huang, Kai
2024-01-31 13:07 ` Huang, Kai
2024-01-31 15:23 ` Baoquan He [this message]
2024-01-31 15:23 ` Baoquan He
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=ZbpmBulaR7eft/CE@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=adrian.hunter@intel.com \
--cc=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=elena.reshetova@intel.com \
--cc=jun.nakajima@intel.com \
--cc=kai.huang@intel.com \
--cc=kexec@lists.infradead.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nik.borisov@suse.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rick.p.edgecombe@intel.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.