public inbox for linux-efi@vger.kernel.org
 help / color / mirror / Atom feed
From: Kiryl Shutsemau <kas@kernel.org>
To: Moritz Sanft <ms@edgeless.systems>
Cc: Dave Hansen <dave.hansen@intel.com>,
	ardb@kernel.org,  "Edgecombe,
	Rick P" <rick.p.edgecombe@intel.com>,
	"Weiny, Ira" <ira.weiny@intel.com>,
	 "Wunner, Lukas" <lukas.wunner@intel.com>,
	linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] Fault during memory acceptance for TDX VMs with certain memory sizes
Date: Fri, 13 Feb 2026 11:56:43 +0000	[thread overview]
Message-ID: <aY8Quu2WJG5HB3PP@thinkstation> (raw)
In-Reply-To: <cf37b7df-1265-411c-8aac-f82c3732fde9@edgeless.systems>

On Fri, Feb 13, 2026 at 09:34:46AM +0100, Moritz Sanft wrote:
> > Any chance you can throw
> > a bunch of printk()'s in the kernel and see what all the fields in here are:
> > 
> > struct efi_unaccepted_memory {
> >         u32 version;
> >         u32 unit_size;
> >         u64 phys_base;
> >         u64 size;
> >         unsigned long bitmap[];
> > };
> > 
> > Along with the address of bitmap[] and all the calls to: bitmap_clear()?
> 
> Thanks for the guidance. I've added this logging via the patch in [1], which
> produced the following output:
> 
> ```
> [    0.033292] accept_memory(start=0x0000000000099000 size=0x6000)
> [    0.037860]   unaccepted: version=1 unit_size=2097152
> phys_base=0x100000000 size=0xfdc bitmap=ff1100007d624030
> [    0.041469] Using GB pages for direct mapping
> [    0.043090] accept_memory(start=0x00000010db600000 size=0x200000)
> [    0.045311]   unaccepted: version=1 unit_size=2097152
> phys_base=0x100000000 size=0xfdc bitmap=ff1100007d624030
> [    0.058123]   bitmap_clear(bitmap=ff1100007d624030, start=32475, len=1)
> [    0.060921] accept_memory(start=0x00000010db7ff000 size=0x1000)
> [    0.063142]   unaccepted: version=1 unit_size=2097152
> phys_base=0x100000000 size=0xfdc bitmap=ff1100007d624030
> [    0.066865] accept_memory(start=0x00000010db7fe000 size=0x1000)
> [    0.069096]   unaccepted: version=1 unit_size=2097152
> phys_base=0x100000000 size=0xfdc bitmap=ff1100007d624030
> [    0.073705] accept_memory(start=0x00000010db7fd000 size=0x1000)
> [    0.075908]   unaccepted: version=1 unit_size=2097152
> phys_base=0x100000000 size=0xfdc bitmap=ff1100007d624030
> // unrelated logs omitted here
> [    0.134988] accept_memory(start=0x00000010db7fcf40 size=0x83)
> [    0.137152]   unaccepted: version=1 unit_size=2097152
> phys_base=0x100000000 size=0xfdc bitmap=ff1100007d624030
> [    0.140828] BUG: unable to handle page fault for address:
> ff1100007d625008
> ```
> 
> Find a full log attached in [2].
> 
> Please let me know if we need to gather any further logs - we're happy to do
> so.

Could you check it this patch makes a difference:

diff --git a/drivers/firmware/efi/unaccepted_memory.c b/drivers/firmware/efi/unaccepted_memory.c
index c2c067eff634..f2a00cd429f2 100644
--- a/drivers/firmware/efi/unaccepted_memory.c
+++ b/drivers/firmware/efi/unaccepted_memory.c
@@ -35,7 +35,7 @@ void accept_memory(phys_addr_t start, unsigned long size)
 	struct efi_unaccepted_memory *unaccepted;
 	unsigned long range_start, range_end;
 	struct accept_range range, *entry;
-	phys_addr_t end = start + size;
+	phys_addr_t end = start + PAGE_ALIGN(size);
 	unsigned long flags;
 	u64 unit_size;
 
-- 
  Kiryl Shutsemau / Kirill A. Shutemov

  reply	other threads:[~2026-02-13 11:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-12 16:29 [BUG] Fault during memory acceptance for TDX VMs with certain memory sizes Moritz Sanft
2026-02-12 23:31 ` Dave Hansen
2026-02-13  8:34   ` Moritz Sanft
2026-02-13 11:56     ` Kiryl Shutsemau [this message]
2026-02-13 12:33       ` Moritz Sanft
2026-02-13 14:24         ` Kiryl Shutsemau
2026-02-13 14:52           ` Moritz Sanft
2026-02-13 14:52           ` Moritz Sanft
2026-02-13 16:53           ` Verma, Vishal L

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=aY8Quu2WJG5HB3PP@thinkstation \
    --to=kas@kernel.org \
    --cc=ardb@kernel.org \
    --cc=dave.hansen@intel.com \
    --cc=ira.weiny@intel.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.wunner@intel.com \
    --cc=ms@edgeless.systems \
    --cc=rick.p.edgecombe@intel.com \
    /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