From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D42CE4657C2 for ; Tue, 16 Jun 2026 18:48:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781635690; cv=none; b=B7G/3zPZOmPae3dEuwIe22UyspYkx46Lc1h7zi9rKImfD2MnF1dlBuez9UeOOQYgVtoiqhWbZExALSyw6I/iedCpJbIwKZe78IX4P9L5nC6RLxLHQTjAgFdIrU9WmfCp3CCX1T9nuJDIghyYWBIxyH13PmbztihNmIaQwVtwKTM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781635690; c=relaxed/simple; bh=Xx05wp4cyHtf9W47TC/Dwjp1vIDUaS1Eegfg4Ib+/tk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=uX9YmveHQlCipJMjBAXRjPnd3cP3X2HJrZn5H3TG+sA4TETA8LbitsDl7Q1cREQJWEgFS8e0Ha2RXuhrzsslnFjm11V57RSSyk9+D3R7Ojx5CxG0jSgqWupisyMZclwBRm+/WihCm1gw8Ku/L4b35Dj86oTYKpKgnNytV4Fu/04= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=obI9eI8p; arc=none smtp.client-ip=209.85.210.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="obI9eI8p" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-84247fed609so2641448b3a.0 for ; Tue, 16 Jun 2026 11:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1781635688; x=1782240488; darn=lists.linux.dev; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=P3dgH42zNflWYjVlKpWQxlbi6GFJLYhVFZGxy7D/Xxg=; b=obI9eI8p6Zg9WJQp21TJ28B5V7JT/L48W3SWENZDjV8wP8AAclK5uxv1E3VlmrcsE9 cb10wifzbnG3czJe1oQ5m4eAcANIIe/DdD1FilfcgIKZa9UXsIcGS91qsssw5OicEnC9 wdK3+HXcc1zyPGd117HZXFc9BCROdOMNONer4UhNixD8ZlRaNwVSmvi2owBItnQfZJKI Ex/ZhfgvzwIZ8ciRUwn4ned8U/wYhqEmTEDXBKjx5vaoeA8ui9aDfQzBtfIf451UBtku fidsqkhnB9LwHmm82sA90gNEz9xDCaNDKE1V/ETcH4vH4r5Lo+apliarQQRFZCXK5pEW IJPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781635688; x=1782240488; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=P3dgH42zNflWYjVlKpWQxlbi6GFJLYhVFZGxy7D/Xxg=; b=f/4QZoUgvzjUorOkKFoPU0uvEa0k2EJwfIxLTq2xh5m3GNywZLLGznlL2LCPW1IfKU PtI69ml/ch5cX89MxsWcigT8bWtUWYt/Lii+V/u2ZP9LNdybk7wQ9bP3C1KMwzb5iK24 Y4StcK8XckI+5KklWDqv4EBFeBghlQpNHCa0aKU3kniSIjuhxPI7DDMvLYySUA1oUIKx xlnUEZRD476F3HgXPkGo+QrgrfkcpN/IYGjzb3IMMF8cw8fm+LI2rcfcjn9R2b45aL8m fnAYgFGp4dFBym81DkQPU41Rnyk+o4Kke39fH+dh9IPwrj3hv0ee0Hx2oHSBRY7jezmf mQ3g== X-Forwarded-Encrypted: i=1; AFNElJ/cXk43He+Zv/KMtIXsIPdCX8EOnclC3LbEwh3u7bP8mdtLMBCggypAR/urjLKvUQx5w8hA080eGKJr@lists.linux.dev X-Gm-Message-State: AOJu0YwgSAxmlSlmLLBD0N6L0uOigCdaqUvd2cbTsm3qNuWELmoAmmcv nynWiHmLX/Sb7STQvMZdFOBf/qeULfYTzO5NkwX1EZMI2jgF4dLkUDhyvfHEHF6eDlckICYlvXc cbPTl6Q== X-Received: from pfbih9.prod.google.com ([2002:a05:6a00:8c09:b0:835:3fa4:894a]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2d25:b0:842:6f13:1461 with SMTP id d2e1a72fcca58-84524476bcdmr384546b3a.11.1781635687806; Tue, 16 Jun 2026 11:48:07 -0700 (PDT) Date: Tue, 16 Jun 2026 11:48:07 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260521-tdx-selftests-v13-v13-0-6983ae4c3a4d@google.com> Message-ID: Subject: Re: [PATCH v13 00/22] TDX KVM selftests From: Sean Christopherson To: Ackerley Tng Cc: Lisa Wang , Andrew Jones , Binbin Wu , Chao Gao , Chenyi Qiang , Dave Hansen , Erdem Aktas , Kiryl Shutsemau , linux-kselftest@vger.kernel.org, Paolo Bonzini , "Pratik R. Sampat" , Reinette Chatre , Rick Edgecombe , Roger Wang , Ryan Afranji , Sagi Shahar , Shuah Khan , Oliver Upton , Jeremiah McReynolds , kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, x86@kernel.org, Adrian Hunter Content-Type: text/plain; charset="us-ascii" On Tue, Jun 16, 2026, Ackerley Tng wrote: > Lisa Wang writes: > > > 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. > > > > Sean, Lisa evaluated your suggestion [1] (summarized as 1. above) but we > think TDCALL MMIO is better, what do you think? I think y'all should have responded to that thread with "that doesn't work because host userspace can't access the registers". Reviews are multi-way discussions, not one-way streams of "do this". And the expectation is that either review feedback is addressed in the next version, or the dicussion is closed/resolved *before* posting the next version. Remaining silent and then writing a thesis in the cover letter of a future version of the series is very inefficient for everyone involved. I obviously don't read cover letters all that closely at v13 and I gotta imagine a *lot* of effort went into the above (which I greatly appreciate!). The paper trail also becomes impossible to follow, because anyone reading my response would probably make the same assumption as me: it was a viable idea and that's what we implemented. I'm a-ok with using MMIO, because yeah, there doesn't seem to be a better option.