Received-SPF: pass (google.com: domain of linux-kernel+bounces-157633-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Wed, 24 Apr 2024 12:57:43 -0700
In-Reply-To: <6f476d85cdb9dfdc0893e9eb762dca08f0f5f19b.camel@intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <cover.1711035400.git.reinette.chatre@intel.com>
 <6fae9b07de98d7f56b903031be4490490042ff90.camel@intel.com>
 <Ziku9m_1hQhJgm_m@google.com> <26073e608fc450c6c0dcfe1f5cb1590f14c71e96.camel@intel.com>
 <ZilAEhUS-mmgjBK8@google.com> <6f476d85cdb9dfdc0893e9eb762dca08f0f5f19b.camel@intel.com>
Message-ID: <ZilaWM4AmrbeSEy0@google.com>
Subject: Re: [PATCH V4 0/4] KVM: x86: Make bus clock frequency for vAPIC timer configurable
From: Sean Christopherson <seanjc@google.com>
To: Rick P Edgecombe <rick.p.edgecombe@intel.com>
Cc: "jmattson@google.com" <jmattson@google.com>, Chao Gao <chao.gao@intel.com>, 
	"vkuznets@redhat.com" <vkuznets@redhat.com>, Vishal Annapurve <vannapurve@google.com>, 
	Xiaoyao Li <xiaoyao.li@intel.com>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Vishal L Verma <vishal.l.verma@intel.com>, 
	Reinette Chatre <reinette.chatre@intel.com>, "pbonzini@redhat.com" <pbonzini@redhat.com>, 
	Erdem Aktas <erdemaktas@google.com>, Isaku Yamahata <isaku.yamahata@intel.com>, 
	"mlevitsk@redhat.com" <mlevitsk@redhat.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"

On Wed, Apr 24, 2024, Rick P Edgecombe wrote:
> Long term though, I have been wondering about how to prevent TDX regressions
> especially on the MMU pieces. It is one thing to have the TDX setups available
> for maintainers, but most normal developers will likely not have access to TDX
> HW for a bit. Just a problem without a solution.

I wouldn't worry too much about hardware availability.  As you said, it's not
a problem we can really solve, and we already have to be concious of the fact
that not all developers have comparable hardware.  E.g. most people don't have
a 4-sock, multi-hundred CPU system with TiBs of RAM.  Not being able to test at
all is obviously a little different, but it's not entirely new.

Instead, I would encourage spending time and effort (after things have settled
down patch wise) to build out selftests.   I tried to run a "real" SEV-ES VM
and gave up because I needed the "right" OVMF build, blah blah blah.  At some
point I'll probably bite the bullet and get a "full" CoCo setup working, but it's
not exactly at the top of my todo list, in no small part because the triage and
debug experience when things go wrong is miles and miles better in selftests.