From: "David Hildenbrand (Red Hat)" <david@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Kiryl Shutsemau <kas@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, ardb@kernel.org,
akpm@linux-foundation.org, osalvador@suse.de,
thomas.lendacky@amd.com, michael.roth@amd.com
Subject: Re: [RFC PATCH 2/4] mm: Add support for unaccepted memory hotplug
Date: Mon, 1 Dec 2025 19:32:38 +0100 [thread overview]
Message-ID: <052d7f47-edb6-4978-bc9a-c7eae469720f@kernel.org> (raw)
In-Reply-To: <20251201111201.GAaS14AX18qeHN20xf@fat_crate.local>
On 12/1/25 12:12, Borislav Petkov wrote:
> On Mon, Dec 01, 2025 at 10:18:37AM +0100, David Hildenbrand (Red Hat) wrote:
>> Makes sense to me, especially for confidential VMs where we pass such
>> kernel-managed data from the old to the new kernel.
>
> It shouldn't matter, right?
>
> I think the question is whether the kernel should agree to the software
> contract (/eyeroll) to keep the kernel ABI compatible wrt kexec.
>
> And I don't think we have agreed to that AFAIK.
I think we are in agreement: from what I recall, this software contract used to be
rather simple and stable.
Looking into the details, I guess it's all about
$ grep "define LINUX_EFI_" include/linux/efi.h
#define LINUX_EFI_CRASH_GUID EFI_GUID(0xcfc8fc79, 0xbe2e, 0x4ddc, 0x97, 0xf0, 0x9f, 0x98, 0xbf, 0xe2, 0x98, 0xa0)
#define LINUX_EFI_SCREEN_INFO_TABLE_GUID EFI_GUID(0xe03fc20a, 0x85dc, 0x406e, 0xb9, 0x0e, 0x4a, 0xb5, 0x02, 0x37, 0x1d, 0x95)
#define LINUX_EFI_ARM_CPU_STATE_TABLE_GUID EFI_GUID(0xef79e4aa, 0x3c3d, 0x4989, 0xb9, 0x02, 0x07, 0xa9, 0x43, 0xe5, 0x50, 0xd2)
#define LINUX_EFI_LOADER_ENTRY_GUID EFI_GUID(0x4a67b082, 0x0a4c, 0x41cf, 0xb6, 0xc7, 0x44, 0x0b, 0x29, 0xbb, 0x8c, 0x4f)
#define LINUX_EFI_RANDOM_SEED_TABLE_GUID EFI_GUID(0x1ce1e5bc, 0x7ceb, 0x42f2, 0x81, 0xe5, 0x8a, 0xad, 0xf1, 0x80, 0xf5, 0x7b)
#define LINUX_EFI_TPM_EVENT_LOG_GUID EFI_GUID(0xb7799cb0, 0xeca2, 0x4943, 0x96, 0x67, 0x1f, 0xae, 0x07, 0xb7, 0x47, 0xfa)
#define LINUX_EFI_MEMRESERVE_TABLE_GUID EFI_GUID(0x888eb0c6, 0x8ede, 0x4ff5, 0xa8, 0xf0, 0x9a, 0xee, 0x5c, 0xb9, 0x77, 0xc2)
#define LINUX_EFI_INITRD_MEDIA_GUID EFI_GUID(0x5568e427, 0x68fc, 0x4f3d, 0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68)
#define LINUX_EFI_MOK_VARIABLE_TABLE_GUID EFI_GUID(0xc451ed2b, 0x9694, 0x45d3, 0xba, 0xba, 0xed, 0x9f, 0x89, 0x88, 0xa3, 0x89)
#define LINUX_EFI_COCO_SECRET_AREA_GUID EFI_GUID(0xadf956ad, 0xe98c, 0x484c, 0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47)
#define LINUX_EFI_BOOT_MEMMAP_GUID EFI_GUID(0x800f683f, 0xd08b, 0x423a, 0xa2, 0x93, 0x96, 0x5c, 0x3c, 0x6f, 0xe2, 0xb4)
#define LINUX_EFI_UNACCEPTED_MEM_TABLE_GUID EFI_GUID(0xd5d1de3c, 0x105c, 0x44f9, 0x9e, 0xa9, 0xbc, 0xef, 0x98, 0x12, 0x00, 0x31)
#define LINUX_EFI_LOADED_IMAGE_FIXED_GUID EFI_GUID(0xf5a37b6d, 0x3344, 0x42a5, 0xb6, 0xbb, 0x97, 0x86, 0x48, 0xc1, 0x89, 0x0a)
Likely the format of these section stayed unchanged over the years.
--
Cheers
David
next prev parent reply other threads:[~2025-12-01 18:32 UTC|newest]
Thread overview: 37+ 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) [this message]
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
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-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=052d7f47-edb6-4978-bc9a-c7eae469720f@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--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=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