Received-SPF: pass (google.com: domain of linux-kernel+bounces-196014-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Thu, 30 May 2024 16:12:44 -0700
In-Reply-To: <f2952ae37a2bdaf3eb53858e54e6cc4986c62528.camel@intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <9bd868a287599eb2a854f6983f13b4500f47d2ae.1708933498.git.isaku.yamahata@intel.com>
 <Zjz7bRcIpe8nL0Gs@google.com> <5ba2b661-0db5-4b49-9489-4d3e72adf7d2@intel.com>
 <Zj1Ty6bqbwst4u_N@google.com> <49b7402c-8895-4d53-ad00-07ce7863894d@intel.com>
 <20240509235522.GA480079@ls.amr.corp.intel.com> <Zj4phpnqYNoNTVeP@google.com>
 <50e09676-4dfc-473f-8b34-7f7a98ab5228@intel.com> <Zle29YsDN5Hff7Lo@google.com>
 <f2952ae37a2bdaf3eb53858e54e6cc4986c62528.camel@intel.com>
Message-ID: <ZliUecH-I1EhN7Ke@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: Tina Zhang <tina.zhang@intel.com>, 
	"isaku.yamahata@linux.intel.com" <isaku.yamahata@linux.intel.com>, Hang Yuan <hang.yuan@intel.com>, 
	Bo Chen <chen.bo@intel.com>, "sagis@google.com" <sagis@google.com>, 
	"isaku.yamahata@gmail.com" <isaku.yamahata@gmail.com>, Erdem Aktas <erdemaktas@google.com>, 
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, "pbonzini@redhat.com" <pbonzini@redhat.com>, 
	Isaku Yamahata <isaku.yamahata@intel.com>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"

On Thu, May 30, 2024, Kai Huang wrote:
> On Wed, 2024-05-29 at 16:15 -0700, Sean Christopherson wrote:
> > In the unlikely event there is a legitimate reason for max_vcpus_per_td being
> > less than KVM's minimum, then we can update KVM's minimum as needed.  But AFAICT,
> > that's purely theoretical at this point, i.e. this is all much ado about nothing.
> 
> I am afraid we already have a legitimate case: TD partitioning.  Isaku
> told me the 'max_vcpus_per_td' is lowed to 512 for the modules with TD
> partitioning supported.  And again this is static, i.e., doesn't require
> TD partitioning to be opt-in to low to 512.

So what's Intel's plan for use cases that creates TDs with >512 vCPUs?

> So AFAICT this isn't a theoretical thing now.
> 
> Also, I want to say I was wrong about "MAX_VCPUS" in the TD_PARAMS is part
> of attestation.  It is not.  TDREPORT dosen't include the "MAX_VCPUS", and
> it is not involved in the calculation of the measurement of the guest.
> 
> Given "MAX_VCPUS" is not part of attestation, I think there's no need to
> allow user to change kvm->max_vcpus by enabling KVM_ENABLE_CAP ioctl() for
> KVM_CAP_MAX_VCPUS.

Sure, but KVM would still need to advertise the reduced value for KVM_CAP_MAX_VCPUS
when queried via KVM_CHECK_EXTENSION.  And userspace needs to be conditioned to
do a VM-scoped check, not a system-scoped check.

> So we could just once for all adjust kvm->max_vcpus for TDX in the
> tdx_vm_init() for TDX guest:
> 
> 	kvm->max_vcpus = min(kvm->max_vcpus, tdx_info->max_vcpus_per_td);
> 
> AFAICT no other change is needed.
> 
> And in KVM_TDX_VM_INIT (where TDH.MNG.INIT is done) we can just use kvm-
> >max_vcpus to fill the "MAX_VCPUS" in TD_PARAMS.