From: Borislav Petkov <bp@alien8.de>
To: Kiryl Shutsemau <kas@kernel.org>
Cc: "David Hildenbrand (Red Hat)" <david@kernel.org>,
ardb@kernel.org, "Pratik R. Sampat" <prsampat@amd.com>,
linux-mm@kvack.org, linux-coco@lists.linux.dev,
linux-efi@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@redhat.com, dave.hansen@linux.intel.com,
akpm@linux-foundation.org, osalvador@suse.de,
thomas.lendacky@amd.com, michael.roth@amd.com,
torvalds@linux-foundation.org
Subject: Re: [RFC PATCH 2/4] mm: Add support for unaccepted memory hotplug
Date: Wed, 3 Dec 2025 16:58:55 +0100 [thread overview]
Message-ID: <20251203155855.GCaTBeP8fQDLx3T0X8@fat_crate.local> (raw)
In-Reply-To: <etd7r45wmnuoftpckrzkzithr443ru6akgwqjgzw2vgmzqi7cs@camfecdmef74>
On Wed, Dec 03, 2025 at 02:46:23PM +0000, Kiryl Shutsemau wrote:
> There is also the #1 Kernel Rule: "we do not break users."
Do I need to point you to that too:
Documentation/process/stable-api-nonsense.rst
?
> Booting a different version of the kernel is a core functionality of
> kexec. It is widely used to deploy new kernels or revert to older ones.
> Breaking this functionality is a show-stopper for most, if not all,
> hyperscalers.
>
> This specific change may not be a show-stopper as CoCo deployment is not
> widespread enough to be noticed yet.
>
> The notion that nobody promised that you can kexec into a different kernel
> is absurd. It is used everywhere.
Dude, can you please stop handwaving and say what you really wanna say: you
want different kernels to kexec. And it has worked so far but nothing
guarantees that. And we should all agree on some strategy going forward and
enforce it.
I don't care if different kernels can kexec or not. If I need to kexec, then
I simply build the same kernel.
So I'd take a patch which breaks that and when the submitter gets stopped by
you or someone else, I'll go tell him: "well, actually, I can't take your
patch because Kiryl said so but that's his opinion."
Do you see how absurd this is?!
Geez, I'm tired of typing the same shit over and over again on this thread.
Feel free to propose to make kexec'ing different kernels a rule and let's all
discuss it but let's stop this nonsense of what worked and so on. The kernel
gets complicated constantly, grows things here and there and without such
a rule, are you going to sit around and guard that kexec works?
Pfff.
> I am not involved in the deployment of CoCo VMs, but I don't believe it
> is specifically about CoCo or the kexec ABI. I think it is more about
> the boot protocol. Kexec is one way to boot the kernel.
>
> Should we consider the EFI configuration tables format as part of the
> boot protocol?
You're basically proving my point: this needs to be discussed and agreed upon.
It doesn't matter if it used to work implicitly in the past.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2025-12-03 15:59 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-25 17:57 [RFC PATCH 0/4] SEV-SNP Unaccepted Memory Hotplug Pratik R. Sampat
2025-11-25 17:57 ` [RFC PATCH 1/4] efi/libstub: Decouple memory bitmap from the unaccepted table Pratik R. Sampat
2025-11-26 11:08 ` Kiryl Shutsemau
2025-11-26 22:27 ` Pratik R. Sampat
2025-11-27 17:29 ` Kiryl Shutsemau
2025-11-25 17:57 ` [RFC PATCH 2/4] mm: Add support for unaccepted memory hotplug Pratik R. Sampat
2025-11-26 11:12 ` Kiryl Shutsemau
2025-11-26 22:27 ` Pratik R. Sampat
2025-11-27 17:40 ` Kiryl Shutsemau
2025-11-28 9:34 ` David Hildenbrand (Red Hat)
2025-12-01 17:15 ` Pratik R. Sampat
2025-12-01 18:25 ` David Hildenbrand (Red Hat)
2025-12-01 19:35 ` Pratik R. Sampat
2025-12-01 17:15 ` Pratik R. Sampat
2025-12-01 17:48 ` Kiryl Shutsemau
2025-12-01 17:58 ` Pratik R. Sampat
2025-11-26 22:31 ` Borislav Petkov
2025-11-27 17:35 ` Kiryl Shutsemau
2025-11-27 18:12 ` Borislav Petkov
2025-11-28 9:30 ` David Hildenbrand (Red Hat)
2025-11-28 11:34 ` Borislav Petkov
2025-12-01 9:18 ` David Hildenbrand (Red Hat)
2025-12-01 11:12 ` Borislav Petkov
2025-12-01 18:32 ` David Hildenbrand (Red Hat)
2025-12-01 19:10 ` Borislav Petkov
2025-12-01 20:10 ` David Hildenbrand (Red Hat)
2025-12-01 20:25 ` Borislav Petkov
2025-12-01 20:36 ` David Hildenbrand (Red Hat)
2025-12-03 14:46 ` Kiryl Shutsemau
2025-12-03 15:58 ` Borislav Petkov [this message]
2025-12-03 15:00 ` Rik van Riel
2025-11-28 9:32 ` David Hildenbrand (Red Hat)
2025-12-01 17:21 ` Pratik R. Sampat
2025-12-01 18:36 ` David Hildenbrand (Red Hat)
2025-12-01 19:35 ` Pratik R. Sampat
2025-12-09 21:36 ` Pratik R. Sampat
2025-12-11 15:00 ` Kiryl Shutsemau
2025-12-11 22:07 ` Pratik R. Sampat
2025-11-25 17:57 ` [RFC PATCH 3/4] x86/sev: Introduce hotplug-aware SNP page state validation Pratik R. Sampat
2025-11-25 17:57 ` [RFC PATCH 4/4] mm: Add support for unaccepted memory hot-remove Pratik R. Sampat
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=20251203155855.GCaTBeP8fQDLx3T0X8@fat_crate.local \
--to=bp@alien8.de \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=kas@kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=osalvador@suse.de \
--cc=prsampat@amd.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=torvalds@linux-foundation.org \
--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