Received-SPF: pass (google.com: domain of linux-kernel+bounces-175051-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Thu, 9 May 2024 15:52:59 -0700
In-Reply-To: <5ba2b661-0db5-4b49-9489-4d3e72adf7d2@intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <cover.1708933498.git.isaku.yamahata@intel.com>
 <9bd868a287599eb2a854f6983f13b4500f47d2ae.1708933498.git.isaku.yamahata@intel.com>
 <Zjz7bRcIpe8nL0Gs@google.com> <5ba2b661-0db5-4b49-9489-4d3e72adf7d2@intel.com>
Message-ID: <Zj1Ty6bqbwst4u_N@google.com>
Subject: Re: [PATCH v19 037/130] KVM: TDX: Make KVM_CAP_MAX_VCPUS backend specific
From: Sean Christopherson <seanjc@google.com>
To: Kai Huang <kai.huang@intel.com>
Cc: isaku.yamahata@intel.com, kvm@vger.kernel.org, 
	linux-kernel@vger.kernel.org, isaku.yamahata@gmail.com, 
	Paolo Bonzini <pbonzini@redhat.com>, erdemaktas@google.com, Sagi Shahar <sagis@google.com>, 
	chen.bo@intel.com, hang.yuan@intel.com, tina.zhang@intel.com
Content-Type: text/plain; charset="us-ascii"

On Fri, May 10, 2024, Kai Huang wrote:
> On 10/05/2024 4:35 am, Sean Christopherson wrote:
> > KVM x86 limits KVM_MAX_VCPUS to 4096:
> > 
> >    config KVM_MAX_NR_VCPUS
> > 	int "Maximum number of vCPUs per KVM guest"
> > 	depends on KVM
> > 	range 1024 4096
> > 	default 4096 if MAXSMP
> > 	default 1024
> > 	help
> > 
> > whereas the limitation from TDX is apprarently simply due to TD_PARAMS taking
> > a 16-bit unsigned value:
> > 
> >    #define TDX_MAX_VCPUS  (~(u16)0)
> > 
> > i.e. it will likely be _years_ before TDX's limitation matters, if it ever does.
> > And _if_ it becomes a problem, we don't necessarily need to have a different
> > _runtime_ limit for TDX, e.g. TDX support could be conditioned on KVM_MAX_NR_VCPUS
> > being <= 64k.
> 
> Actually later versions of TDX module (starting from 1.5 AFAICT), the module
> has a metadata field to report the maximum vCPUs that the module can support
> for all TDX guests.

My quick glance at the 1.5 source shows that the limit is still effectively
0xffff, so again, who cares?  Assert on 0xffff compile time, and on the reported
max at runtime and simply refuse to use a TDX module that has dropped the minimum
below 0xffff.

> And we only allow the kvm->max_vcpus to be updated if it's a TDX guest in
> the vt_vm_enable_cap().  The reason is we want to avoid unnecessary change
> for normal VMX guests.

That's a frankly ridiculous reason to bury code in TDX.  Nothing is _forcing_
userspace to set KVM_CAP_MAX_VCPUS, i.e. there won't be any change to VMX VMs
unless userspace _wants_ there to be a change.