[PATCH] x86/unaccepted_memory: Do not accept ranges that are no longer E820 RAM

[PATCH] x86/unaccepted_memory: Do not accept ranges that are no longer E820 RAM

[Pankaj Gupta]

The EFI stub builds the unaccepted memory bitmap before the kernel parses
its command line.  Option memmap=<size>$<addr> removes RAM from the E820
map while its bits are still set in the bitmap.

The removed range, such as a memmap=...$... hole, is then still treated as
unaccepted RAM and accept_memory() tries to accept it.  The hole is not
mapped, so on SEV-SNP the PVALIDATE faults and the guest crashes early in
the boot:

  BUG: unable to handle page fault for address: ffff8a14bfe00000
  RIP: 0010:pvalidate_pages+0xc0/0x250
   set_pages_state+0x41a/0x440
   snp_accept_memory+0x3e/0x50
   accept_memory+0x186/0x260
   __free_pages_core+0xd2/0x240
   memblock_free_pages+0x1b/0x30
   memblock_free_all+0x275/0x2d0

This was seen with memmap=2M$0x1ffe00000, a 2 MiB hole in RAM, on a 19 GiB
SNP guest with lazy acceptance.

Fixes: 2053bc57f367 ("efi: Add unaccepted memory support")
Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com>
---
 arch/x86/include/asm/unaccepted_memory.h | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/unaccepted_memory.h b/arch/x86/include/asm/unaccepted_memory.h
index f5937e9866ac..744f1a993352 100644
--- a/arch/x86/include/asm/unaccepted_memory.h
+++ b/arch/x86/include/asm/unaccepted_memory.h
@@ -2,10 +2,11 @@
 #define _ASM_X86_UNACCEPTED_MEMORY_H
 
 #include <linux/efi.h>
+#include <asm/e820/api.h>
 #include <asm/tdx.h>
 #include <asm/sev.h>
 
-static inline void arch_accept_memory(phys_addr_t start, phys_addr_t end)
+static inline void __arch_accept_memory(phys_addr_t start, phys_addr_t end)
 {
 	/* Platform-specific memory-acceptance call goes here */
 	if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) {
@@ -18,6 +19,26 @@ static inline void arch_accept_memory(phys_addr_t start, phys_addr_t end)
 	}
 }
 
+static inline void arch_accept_memory(phys_addr_t start, phys_addr_t end)
+{
+	u32 i;
+
+	for (i = 0; i < e820_table->nr_entries; i++) {
+		struct e820_entry *entry = &e820_table->entries[i];
+		phys_addr_t s, e;
+
+		if (entry->type != E820_TYPE_RAM)
+			continue;
+
+		s = max_t(phys_addr_t, start, entry->addr);
+		e = min_t(phys_addr_t, end, entry->addr + entry->size);
+		if (s >= e)
+			continue;
+
+		__arch_accept_memory(s, e);
+	}
+}
+
 static inline struct efi_unaccepted_memory *efi_get_unaccepted_table(void)
 {
 	if (efi.unaccepted == EFI_INVALID_TABLE_ADDR)
-- 
2.34.1

Re: [PATCH] x86/unaccepted_memory: Do not accept ranges that are no longer E820 RAM

[Ard Biesheuvel]

Hello Pankaj,

On Mon, 2 Nov 2026, at 12:31, Pankaj Gupta wrote:
> The EFI stub builds the unaccepted memory bitmap before the kernel parses
> its command line.  Option memmap=<size>$<addr> removes RAM from the E820
> map while its bits are still set in the bitmap.
>
> The removed range, such as a memmap=...$... hole, is then still treated as
> unaccepted RAM and accept_memory() tries to accept it.  The hole is not
> mapped, so on SEV-SNP the PVALIDATE faults and the guest crashes early in
> the boot:
>
>   BUG: unable to handle page fault for address: ffff8a14bfe00000
>   RIP: 0010:pvalidate_pages+0xc0/0x250
>    set_pages_state+0x41a/0x440
>    snp_accept_memory+0x3e/0x50
>    accept_memory+0x186/0x260
>    __free_pages_core+0xd2/0x240
>    memblock_free_pages+0x1b/0x30
>    memblock_free_all+0x275/0x2d0
>
> This was seen with memmap=2M$0x1ffe00000, a 2 MiB hole in RAM, on a 19 GiB
> SNP guest with lazy acceptance.
>
> Fixes: 2053bc57f367 ("efi: Add unaccepted memory support")
> Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com>
> ---
>  arch/x86/include/asm/unaccepted_memory.h | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
>

Can we just disallow memmap= when running in a confidential VM?

Re: [PATCH] x86/unaccepted_memory: Do not accept ranges that are no longer E820 RAM

[Gupta, Pankaj]

Hi Ard,

> Hello Pankaj,
>
> On Mon, 2 Nov 2026, at 12:31, Pankaj Gupta wrote:
>> The EFI stub builds the unaccepted memory bitmap before the kernel parses
>> its command line.  Option memmap=<size>$<addr> removes RAM from the E820
>> map while its bits are still set in the bitmap.
>>
>> The removed range, such as a memmap=...$... hole, is then still treated as
>> unaccepted RAM and accept_memory() tries to accept it.  The hole is not
>> mapped, so on SEV-SNP the PVALIDATE faults and the guest crashes early in
>> the boot:
>>
>>    BUG: unable to handle page fault for address: ffff8a14bfe00000
>>    RIP: 0010:pvalidate_pages+0xc0/0x250
>>     set_pages_state+0x41a/0x440
>>     snp_accept_memory+0x3e/0x50
>>     accept_memory+0x186/0x260
>>     __free_pages_core+0xd2/0x240
>>     memblock_free_pages+0x1b/0x30
>>     memblock_free_all+0x275/0x2d0
>>
>> This was seen with memmap=2M$0x1ffe00000, a 2 MiB hole in RAM, on a 19 GiB
>> SNP guest with lazy acceptance.
>>
>> Fixes: 2053bc57f367 ("efi: Add unaccepted memory support")
>> Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com>
>> ---
>>   arch/x86/include/asm/unaccepted_memory.h | 23 ++++++++++++++++++++++-
>>   1 file changed, 22 insertions(+), 1 deletion(-)
>>
> Can we just disallow memmap= when running in a confidential VM?

My experiments showed: memmap itself don't have a problem but memap with 
a hole is causing crash.

There might be some usecases which are already using this, e.g:

https://lore.kernel.org/all/20261029-cma-multi-v1-0-2cbced8b5cb7@kernel.org/

Thanks,

Pankaj


>

Re: [PATCH] x86/unaccepted_memory: Do not accept ranges that are no longer E820 RAM

[Gupta, Pankaj]

>>>
>> Can we just disallow memmap= when running in a confidential VM?
>
> My experiments showed: memmap itself don't have a problem but memap 
> with a hole is causing crash.
>
> There might be some usecases which are already using this, e.g:
>
> https://lore.kernel.org/all/20261029-cma-multi-v1-0-2cbced8b5cb7@kernel.org/ 
>
>
Its also good to have a general safeguard to not accept memory that is 
not marked as RAM in e820?

Thanks,

Pankaj

Re: [PATCH] x86/unaccepted_memory: Do not accept ranges that are no longer E820 RAM

[Ard Biesheuvel]

On Mon, 2 Nov 2026, at 13:01, Gupta, Pankaj wrote:
>>>>
>>> Can we just disallow memmap= when running in a confidential VM?
>>
>> My experiments showed: memmap itself don't have a problem but memap 
>> with a hole is causing crash.
>>
>> There might be some usecases which are already using this, e.g:
>>
>> https://lore.kernel.org/all/20261029-cma-multi-v1-0-2cbced8b5cb7@kernel.org/ 
>>
>>
> Its also good to have a general safeguard to not accept memory that is 
> not marked as RAM in e820?
>

Personally, I think all these command line hacks should be avoided in
confidential VMs, on the basis that the firmware's view of memory should
be in sync with the OS.

Re: [PATCH] x86/unaccepted_memory: Do not accept ranges that are no longer E820 RAM

[Gupta, Pankaj]

>>>> Can we just disallow memmap= when running in a confidential VM?
>>> My experiments showed: memmap itself don't have a problem but memap
>>> with a hole is causing crash.
>>>
>>> There might be some usecases which are already using this, e.g:
>>>
>>> https://lore.kernel.org/all/20261029-cma-multi-v1-0-2cbced8b5cb7@kernel.org/
>>>
>>>
>> Its also good to have a general safeguard to not accept memory that is
>> not marked as RAM in e820?
>>
> Personally, I think all these command line hacks should be avoided in
> confidential VMs, on the basis that the firmware's view of memory should
> be in sync with the OS.
Fair enough. I can post a separate on top RFC patch to disable memmap= 
holes completely
for confidential guests and see if anybody objects.

That said, this patch fixes a real crash with memmap= holes 
functionality in confidential guests today,
and should be backported to stable kernels as well. It also hardens the 
existing code to only accept the
e820 RAM regions.

Thanks for having a look!

Pankaj