[BUG] Fault during memory acceptance for TDX VMs with certain memory sizes
From: Moritz Sanft
Date: Thu Feb 12 2026 - 11:34:53 EST
Dear Ard Biesheuvel,
We are running into a kernel panic when starting TDX VMs with certain configurations of memory size in QEMU. The issue reproduces on both mainline and the current 6.18 stable and 6.12 LTS kernels.
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:
- `-m 66690M` results in the crash.
- `-m 66900M` results in the crash.
- `-m 67000M` results in the crash.
- `-m 67G` does not crash.
- `-m 68608M` (67 * 1024) does not crash.
- `-m 6960M` does not crash.
- `-m 33960M` does not crash.
Note that QEMU interprets `67G` in terms of powers of 2, i.e., a multiple of 1024, as can be seen in [1].
The crash happens during memory acceptance in _find_next_bit (although, I presume, accept_memory) is the more revealing thing here:
```
[ 0.111989] BUG: unable to handle page fault for address: ff1100007d625008
[ 0.114651] #PF: supervisor read access in kernel mode
[ 0.116645] #PF: error_code(0x0000) - not-present page
[ 0.118539] PGD 40801067 P4D 40802067 PUD 10db7ff067 PMD 10db7fe067 PTE 0
[ 0.121108] Oops: Oops: 0000 [#1] SMP NOPTI
[ 0.122729] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.19.0 #1-NixOS NONE
[ 0.125651] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
[ 0.128650] RIP: 0010:_find_next_bit+0x1e/0x80
[ 0.130217] Code: c1 c3 c3 66 0f 1f 84 00 00 00 00 00 49 89 f8 48 89 f0 48 39 f2 73 5a 48 89 d6 48 c7 c7 ff ff ff ff 89 d1 48 c1 ee 06 48 d3 e7 <49> 23 3c f0 75 42 48 8d 56 01 49 8d 4c f0 08 48 c1 e2 06 eb 2d 66
[ 0.137510] RSP: 0000:ffffffff91603d28 EFLAGS: 00010087
[ 0.139634] RAX: 0000000000007edc RBX: 0000000000000000 RCX: 0000000000007edb
[ 0.142417] RDX: 0000000000007edb RSI: 00000000000001fb RDI: fffffffff8000000
[ 0.145263] RBP: ffffffff91603da8 R08: ff1100007d624030 R09: ffffffff91c2d090
[ 0.148058] R10: 0000000000000083 R11: ffffffff916beb78 R12: 00000000ffffffff
[ 0.150849] R13: ff1100007d624030 R14: 0000000000200000 R15: ff1100007d624018
[ 0.153702] FS: 0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000
[ 0.156962] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.159239] CR2: ff1100007d625008 CR3: 000000003fe1a000 CR4: 00000000000210f0
[ 0.162088] Call Trace:
[ 0.163075] <TASK>
[ 0.163882] ? accept_memory+0x184/0x250
[ 0.165448] ? memblock_alloc_range_nid+0x16b/0x180
[ 0.167308] ? memblock_alloc_internal+0x38/0x70
[ 0.168997] ? __memblock_alloc_or_panic+0x8c/0xe0
[ 0.170835] ? copy_device_tree+0x1e/0x40
[ 0.172368] ? unflatten_device_tree+0x5e/0x90
[ 0.174074] ? x86_flattree_get_config+0x9b/0xe0
[ 0.175865] ? setup_arch+0x948/0xa50
[ 0.177264] ? start_kernel+0x48/0x6f0
[ 0.178768] ? x86_64_start_reservations+0x20/0x20
[ 0.180610] ? x86_64_start_kernel+0xcd/0xd0
[ 0.182265] ? common_startup_64+0x13e/0x141
[ 0.183921] </TASK>
[ 0.184767] Modules linked in:
[ 0.185971] CR2: ff1100007d625008
[ 0.187308] ---[ end trace 0000000000000000 ]---
[ 0.189071] RIP: 0010:_find_next_bit+0x1e/0x80
[ 0.190789] Code: c1 c3 c3 66 0f 1f 84 00 00 00 00 00 49 89 f8 48 89 f0 48 39 f2 73 5a 48 89 d6 48 c7 c7 ff ff ff ff 89 d1 48 c1 ee 06 48 d3 e7 <49> 23 3c f0 75 42 48 8d 56 01 49 8d 4c f0 08 48 c1 e2 06 eb 2d 66
[ 0.198025] RSP: 0000:ffffffff91603d28 EFLAGS: 00010087
[ 0.200114] RAX: 0000000000007edc RBX: 0000000000000000 RCX: 0000000000007edb
[ 0.202992] RDX: 0000000000007edb RSI: 00000000000001fb RDI: fffffffff8000000
[ 0.205779] RBP: ffffffff91603da8 R08: ff1100007d624030 R09: ffffffff91c2d090
[ 0.208578] R10: 0000000000000083 R11: ffffffff916beb78 R12: 00000000ffffffff
[ 0.211444] R13: ff1100007d624030 R14: 0000000000200000 R15: ff1100007d624018
[ 0.214223] FS: 0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000
[ 0.217326] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.219588] CR2: ff1100007d625008 CR3: 000000003fe1a000 CR4: 00000000000210f0
[ 0.222420] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.226193] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
```
Please find a full log at [2].
The used kernel configuration can be found at [3].
The following QEMU command can be used to reproduce the issue:
```
qemu-system-x86_64 \
-machine q35,accel=kvm,kernel_irqchip=split,confidential-guest-support=tdx \
-cpu host,pmu=off \
-m 67000M \
-object '{"qom-type":"tdx-guest","id":"tdx"}' \
-display none \
-vga none \
-nodefaults \
--no-reboot \
-kernel "/path/to/kernel-binary" \
-append "earlyprintk=ttyS0 console=ttyS0" \
-serial stdio \
-bios "/path/to/OVMF.fd" \
-smp 1
```
We have verified this on QEMU v10.1.2 and OVMF version 202511. The former is necessary for support of TDX VM creation without further patches, whereas the OVMF version should not be of essential importance to the reproduction of this bug.
I do assume that this might be more fit to report to maintainers of the TDX subsystems due to the hardware requirements for the reproduction. However, I decided to report this to you first, as it concerns the EFI subsystem to some extent, at least. Please let me know if you have a recommendation on who to forward this to.
Best Regards,
Moritz Sanft
[1]: <https://gitlab.com/qemu-project/qemu/-/blob/v10.1.2/util/cutils.c?ref_type=tags#L368-371>
[2]: <https://gist.github.com/msanft/45d576466cc5483aef40946213790fcb>
[3]: <https://gist.github.com/msanft/0be5ee612c51df3fd307e449b1f04461>