This patch series focuses on setting up a TDX VM and adding all code necessary to run a basic lifecycle test.
Unlike standard KVM selftests can set up the VM through guest registers, TDX module protects TDs' register state from the host. This feature of TDX causes problems on VM boot state initialization and the ucall implementation. In standard KVM selftests, the host directly initializes the guest state by manipulating Special Registers (SREGs) and General Purpose Registers (GPRs) via IOCTLs (KVM_SET_SREGS, etc.) before the first KVM_RUN. To bypass direct register initialization by the host, we utilize the standard x86 reset vector as the default entry point. The mechanism works as follows: 1. The host places register values into a specific memory region and inserts boot code at the VM's default starting point. 2. When the VM starts, it executes this boot code to "pull" values from memory and manually set up its own SREGs and GPRs. 3. Once the environment is ready, the boot code jumps to the guest code. The standard x86 ucall() implementation uses PIO, but it does not actually transmit data through the 4-byte PIO data. Instead, it relies on the host reading the ucall address directly from the guest's RDI register. TDX selftests cannot utilize the standard x86 ucall implementation, because the host is unable to access the guest's RDI register. Based on this restriction, we considered these potential solutions for the TDX ucall implementation. 1. TDCALL PIO with RCX-bits Passthrough We first considered passing the RDI value through RCX bits to bypass the hardware's register protection, which could be the closest approach to the non-TDX implementation as per Sean's suggestion[1]. However, this approach is blocked by the software-side implementation: KVM_GET_REGS currently does not support TDX VMs and returns -EINVAL. To make this work, the KVM ioctl would need a test-only hack. 2. TDCALL PIO with buffer indexing To keep a PIO-based approach and unify the get_ucall implementation for both TDX and non-TDX VMs, we considered TDCALL PIO with buffer indexing. Since the ucall buffer is initialized prior to execution, the VM could just pass a buffer index rather than an 8-byte ucall address to fit within the 4-byte PIO data limit. The host, already knowing the ucall buffer's base address, could then resolve the ucall content via this index. We abandoned this solution because it would require changes to the common ucall structure and impact other non-x86 architectures. 3. TDCALL MMIO (Selected solution) We ultimately selected TDCALL with an 8-byte MMIO data. This method only requires initializing an MMIO GPA and adding TDCALL MMIO implementation for TDX under the original x86 ucall path. While this diverges from the non-TDX PIO, it provides the cleanest implementation with minimal disruption to the overall ucall architecture. 4. A note on #VE and x86 ucall simplification It is worth noting that the use of a Virtualization Exception (#VE) is orthogonal to the PIO vs. MMIO discussion; rather, it is a question of how much we want to simplify the x86 ucall implementation. A #VE handler is one option to allow VMs use PIO/MMIO identical to the non-TDX case. Alternatively, having an MMIO_WRITE wrapper macro, as Sean suggested[2], is another option. Either way, discussion for this is likely a premature optimization right now, since the PIO/MMIO call is only used under ucall_arch_do_ucall(), and standard and TDX VMs use different ones now. We should optimize this in the future, but for now, invoking TDCALL directly is more robust and concise. v13 revision for TDX KVM selftests based on kvm/next and guest_memfd: In-place conversion support[3]. For ease of testing, this series is also available at: https://github.com/googleprodkernel/linux-cc/commits/tdx-selftests-v13 Changes from v12[4]: 1. Fixed some bugs, including typo, commit order and commit messages. 2. Inlined the TDCALL to tdx.c file. 3. Refactored the Makefile to use pattern rules for generic source compilation while ensuring build artifacts are directed to the target output directory. Series is organized by: 1. Patches 1 - 4: Initialize the TDX VM 2. Patches 5 - 8: Add the TDX boot code 3. Patches 9 - 13: Set up the boot region 4. Patches 14 - 17: Set up the vCPU 5. Patches 18 - 19: Finalize the TDX VM 6. Patches 20 - 22: Implement the ucall and run the TDX test [1]: https://lore.kernel.org/kvm/[email protected]/ [2]: https://lore.kernel.org/kvm/[email protected]/ [3]: https://lore.kernel.org/all/[email protected]/T/ [4]: https://lore.kernel.org/kvm/[email protected]/ Signed-off-by: Lisa Wang <[email protected]> --- Ackerley Tng (2): KVM: selftests: Add helpers to init TDX memory and finalize VM KVM: selftests: Add ucall support for TDX Erdem Aktas (2): KVM: selftests: Add TDX boot code KVM: selftests: Implement MMIO WRITE for the TDX VM Isaku Yamahata (2): KVM: selftests: Update kvm_init_vm_address_properties() for TDX KVM: selftests: TDX: Use KVM_TDX_CAPABILITIES to validate TDs' attribute configuration Lisa Wang (2): KVM: selftests: Back the first memory region with guest_memfd for TDX KVM: selftests: Set first memory region as shared if guest_memfd Sagi Shahar (13): KVM: selftests: Initialize the TDX VM KVM: selftests: Expose segment definitions to assembly files tools: include: Add kbuild.h for assembly structure offsets KVM: selftests: Introduce structures for TDX guest boot parameters KVM: selftests: Expose functions to get default sregs values KVM: selftests: Set up TDX boot code region KVM: selftests: Set up TDX boot parameters region KVM: selftests: Expose function to allocate vCPU stack KVM: selftests: Call KVM_TDX_INIT_VCPU when creating a new TDX vcpu KVM: selftests: Load per-vCPU guest stack in TDX boot parameters KVM: selftests: Set entry point for TDX guest code KVM: selftests: Finalize TD memory as part of kvm_arch_vm_finalize_vcpus KVM: selftests: Add TDX lifecycle test Sean Christopherson (1): KVM: selftests: Add macros to simplify creating VM shapes for non-default types tools/include/linux/kbuild.h | 11 + tools/testing/selftests/kvm/.gitignore | 3 +- tools/testing/selftests/kvm/Makefile.kvm | 33 +- tools/testing/selftests/kvm/include/kvm_util.h | 13 + .../testing/selftests/kvm/include/x86/processor.h | 40 +++ .../selftests/kvm/include/x86/processor_asm.h | 12 + tools/testing/selftests/kvm/include/x86/sev.h | 2 - .../selftests/kvm/include/x86/tdx/td_boot.h | 74 +++++ .../selftests/kvm/include/x86/tdx/td_boot_asm.h | 16 + tools/testing/selftests/kvm/include/x86/tdx/tdx.h | 16 + .../selftests/kvm/include/x86/tdx/tdx_util.h | 80 +++++ tools/testing/selftests/kvm/include/x86/ucall.h | 6 - tools/testing/selftests/kvm/lib/kvm_util.c | 18 +- tools/testing/selftests/kvm/lib/x86/processor.c | 107 ++++--- tools/testing/selftests/kvm/lib/x86/sev.c | 16 - tools/testing/selftests/kvm/lib/x86/tdx/td_boot.S | 60 ++++ .../selftests/kvm/lib/x86/tdx/td_boot_offsets.c | 21 ++ tools/testing/selftests/kvm/lib/x86/tdx/tdx.c | 30 ++ tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c | 334 +++++++++++++++++++++ tools/testing/selftests/kvm/lib/x86/ucall.c | 30 ++ tools/testing/selftests/kvm/x86/sev_smoke_test.c | 40 +-- tools/testing/selftests/kvm/x86/tdx_vm_test.c | 33 ++ 22 files changed, 907 insertions(+), 88 deletions(-) --- base-commit: cd1b71113e3f70f0a1a3d61550cf89f1eed379c4 change-id: 20260508-tdx-selftests-v13-bf00ad0cb8fe Best regards, -- Lisa Wang <[email protected]>
