From: Dave Hansen <dave.hansen@intel.com>
To: Moritz Sanft <ms@edgeless.systems>,
ardb@kernel.org, "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
Kiryl Shutsemau <kas@kernel.org>,
"Weiny, Ira" <ira.weiny@intel.com>,
"Wunner, Lukas" <lukas.wunner@intel.com>
Cc: 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: Thu, 12 Feb 2026 15:31:37 -0800 [thread overview]
Message-ID: <b6f00f31-ab39-4a76-b758-b3cfb1b0dfbe@intel.com> (raw)
In-Reply-To: <c2632da9-745d-46d8-901a-604008a14ac4@edgeless.systems>
On 2/12/26 08:29, Moritz Sanft wrote:
> Based on our current (trial-and-error-based) knowledge, the issue only
> occurs on TDX VMs with memory sizes >64GB, where the memory size is not
> aligned to a multiple of 1024. For instance, the QEMU argument `-m 67G`
> works, while `-m 67000M` results in the crash cited below. The
> configurations we've tested so far are as follows:
I don't see any outrageous bugs in the code. I'm going to take a guess
though: the 'unit_size' and the bitmap size don't match or aren't
consistent.
I'd guess that _something_ is unaligned and you're running off the end
of the bitmap or the *mapping* for the bitmap. 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()?
That that should shed some light on it.
Any other TDX folks that want to try and reproduce this and do the same
would also be much appreciated!
next prev parent reply other threads:[~2026-02-12 23:31 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 [this message]
2026-02-13 8:34 ` Moritz Sanft
2026-02-13 11:56 ` Kiryl Shutsemau
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=b6f00f31-ab39-4a76-b758-b3cfb1b0dfbe@intel.com \
--to=dave.hansen@intel.com \
--cc=ardb@kernel.org \
--cc=ira.weiny@intel.com \
--cc=kas@kernel.org \
--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