Received-SPF: pass (google.com: domain of linux-kernel+bounces-175069-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <49b7402c-8895-4d53-ad00-07ce7863894d@intel.com>
Date: Fri, 10 May 2024 11:19:44 +1200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v19 037/130] KVM: TDX: Make KVM_CAP_MAX_VCPUS backend
 specific
To: Sean Christopherson <seanjc@google.com>
CC: "Yamahata, Isaku" <isaku.yamahata@intel.com>, "kvm@vger.kernel.org"
	<kvm@vger.kernel.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "isaku.yamahata@gmail.com"
	<isaku.yamahata@gmail.com>, Paolo Bonzini <pbonzini@redhat.com>, "Aktas,
 Erdem" <erdemaktas@google.com>, Sagi Shahar <sagis@google.com>, "Chen, Bo2"
	<chen.bo@intel.com>, "Yuan, Hang" <hang.yuan@intel.com>, "Zhang, Tina"
	<tina.zhang@intel.com>
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>
 <Zj1Ty6bqbwst4u_N@google.com>
Content-Language: en-US
From: "Huang, Kai" <kai.huang@intel.com>
In-Reply-To: <Zj1Ty6bqbwst4u_N@google.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OEViN2NjMVRSbFkzcmd1YURuei9NRkkzcUY1bVlTQlJEc0ZQcVY4cjVhK0hx?=
 =?utf-8?B?TTIzL1lWM3hJazVEK0lpdFo2ZlA3UGJwbytVb1lYeXFUSHYvRVBmUURJOWlF?=
 =?utf-8?B?L1BUYWYwc2c1MGVteCs5TEQ2a3h4MndMUEhCQzEzV2tjL05XaUZuYjBlRVFn?=
 =?utf-8?B?WkRBTVFlalh0OUJ6Q0lsMUNxYWtTdXV5cCtEa2VoajhHYUNkSUlYanNLSU5B?=
 =?utf-8?B?aWdOK2hZamRlV2R6NGJpRDdCSTF0ZUN3N29GTE5yaUNKSVF3UUxwYTNtenlI?=
 =?utf-8?B?cW1EN2VKTFBFeFgyYnBxTTQwcHphU1dDTFBsUDlVa1FMRHNTZ1BvdC9tMk9a?=
 =?utf-8?B?REdVYkF0WFhNN3RQRUpCaklBOUtFdTJDbmVuSUk1VnB4eVg1Z3ZpenlEeTNm?=
 =?utf-8?B?c2x6MUZCREhPSHp5WWE2QVJJN3RDY0twVkRXWVZSamxtVStnRkNsZ0p2MTFB?=
 =?utf-8?B?VzVXMGUrQkFERmtpdzdLNm16RS9LTDJ2OFR6ZmJnUUthS0hJSTF0YURjNU8y?=
 =?utf-8?B?cUU5Rm82eDk3VHRHeStsbFdjTktieXNkSHorSGdDTWgwL0wxQzFzVzFRS0Rj?=
 =?utf-8?B?ZkFyVkNiYnorbHZ0NXdIMzBlOVJmTzRjaDJ1ckxlUXZrQWluSlBveFdaV2Iw?=
 =?utf-8?B?VE9SNUc3MVNmR2wvQ2pybktYZFlLakk3Zks2VUUwM2JiWkY2NlFaUUtXZnp3?=
 =?utf-8?B?cThlT3BCRm5YWTFVTlF3ZkcwaTAzVFdqZWhEMHBzMzdlRnl1WGhVWUZWQUFw?=
 =?utf-8?B?VS9WdzJKczRkTXFlUyt4bUdneWpLNHEySVgrWWF2MlJ5bE9Ba1VZb2V3RVM2?=
 =?utf-8?B?NkdRdnoyVkltNWFaLytpOU1wNndYTU9xaWZJdWdtcDhHQUsrTlZQVnZ6Vzhu?=
 =?utf-8?B?SEpNaEV5ZkNuSVVKNzgvdXUrUEVXZlg1R1VyWEgzNFU2bHVPR01Xaks1eWVU?=
 =?utf-8?B?RW9uQmlCcTV0YWRYaktKUGx2SmllTFBTMkFGTy8yanRocWd6THNsUTBkcW1Z?=
 =?utf-8?B?SlFTQ0NlejNWOVhubzVKNnFjSFlsck1TZWM2SlhHNVRQa29pbDZHdG1pZWU4?=
 =?utf-8?B?R0FjYklxY2Y2Y0Y1UnJJQUR3UTNMNUlWUVhkWUc2eUdma3dVRlIwNUo0Q0F0?=
 =?utf-8?B?VERPaGp0Qm53TS96emF0Qkp5UVZDNURzcVRXWkZqTnhiMURINDJ1REVBVXRM?=
 =?utf-8?B?emNvR3NQbENhUXg3SzZ5enBnMVcwTjFteVlpcTE3cFpORTNaMnVra2FaVzI4?=
 =?utf-8?B?S1VvSlFLeEdhVmxSVUY5STNNYjFMWm5INzd2NldYbWgyR3p0ZVVmR2s4VVdX?=
 =?utf-8?B?V3dVWGRMblp2S0tmS2YyNVhSdEFtZmNlRWtSYUM0K3RSL0dSSXRTYlprN3V1?=
 =?utf-8?B?dnVmSEw3RnBrUlQ4S2pWUUhRWW9yVVlHeEcwVS9wYnRicnZibHoyRUdtQUZV?=
 =?utf-8?B?MVl5MTkyZDNFSDl2MUNBbm05R1h6Zk5PSGhoM01wYTJKNVY0VUNtZDdQRGxD?=
 =?utf-8?B?ZEoyck9RVFRrb21GQVU0Qk1xWjNBQ2hQUXFEZ1BMTXRSUkZ0VzY1STZsR3BL?=
 =?utf-8?B?L1NyNFBnSFlzbUdrdjU5L2dRMFRTZHl1N1dDejRlWnhxcWRSY2ZYSlh4QmFO?=
 =?utf-8?B?MjZkb0dIajhTdVJ2eDByQ1BqZmZpMzBVSkZUL2g5M1hWUWo3NHVwdVZHMnRi?=
 =?utf-8?B?azd2S2ZNcWxDTFI4WmNGQm11WWE0L0w4d1RJbm1ZL3BucWtyN2R0S2R1UWVn?=
 =?utf-8?B?VVBCdUZDQjQvYWN4Q3FzcE8wVVF0aTlIaktKWWY1MXExQlZzL1ZkSm8xWldz?=
 =?utf-8?B?Y1gzdWFGK00vQWkwaXlTWU5KNVVxVWFERzZFSU9YemV1bm5ZbTIrTENzSkox?=
 =?utf-8?B?alpzdTkrRFgrdHEwQmY5V25oTHRVWDBFMTF2eEI4cHZteTRsV0Y3cE43MGla?=
 =?utf-8?B?N0U3NStGYjhJcjkrSmpTVVk4MmFHZCtIRldjUkFKbW44V3hYZy9sbGM0T2dI?=
 =?utf-8?B?NU05dU5tdHFWTUM4ZXdSTW8xU0ZBYmMyY1pESzNMSDQzZy9teVM3ZUVoR0lN?=
 =?utf-8?B?MHpoamdRcHEzQngrb1hwRE15eVAxZmZmNFZzMk5oZSt2clpCREdKcWVmdTRv?=
 =?utf-8?Q?NmJM9JVKtAS9enKOpQCx89Zfy?=
X-MS-Exchange-CrossTenant-Network-Message-Id: edff1b02-7582-4a4c-cde6-08dc707e884c
X-MS-Exchange-CrossTenant-AuthSource: BL1PR11MB5978.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2024 23:19:53.6587
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: AHEz+rzH13nQPCylPdSunJA/TdwemPn5KrAXDr+l1U50ev5IOJa5ITZZbSy9jxbt0zV+BOwhoc77snww47OQGw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6067
X-OriginatorOrg: intel.com


On 10/05/2024 10:52 am, Sean Christopherson wrote:
> 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.

I need to double check why this metadata field was added.  My concern is 
in future module versions they may just low down the value.

But another way to handle is we can adjust code when that truly happens? 
Might not be ideal for stable kernel situation, though?

> 
>> 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.

Right.  Anyway allowing userspace to set KVM_CAP_MAX_VCPUS for non-TDX 
guests shouldn't have any issue.

The main reason to bury code in TDX is it needs to additionally check 
tdx_info->max_vcpus_per_td.  We can just do in common code if we avoid 
that TDX specific check.