All of lore.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 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.