On Mon, Mar 25, 2024 at 04:42:36PM +0800, Binbin Wu <binbin.wu@xxxxxxxxxxxxxxx> wrote: > > > On 3/23/2024 9:13 AM, Isaku Yamahata wrote: > > On Fri, Mar 22, 2024 at 12:36:40PM +1300, > > "Huang, Kai" <kai.huang@xxxxxxxxx> wrote: > > > > > So how about: > > Thanks for it. I'll update the commit message with some minor fixes. > > > > > " > > > TDX has its own mechanism to control the maximum number of VCPUs that the > > > TDX guest can use. When creating a TDX guest, the maximum number of vcpus > > > needs to be passed to the TDX module as part of the measurement of the > > > guest. > > > > > > Because the value is part of the measurement, thus part of attestation, it > > ^'s > > > better to allow the userspace to be able to configure it. E.g. the users > > the userspace to configure it ^, > > > may want to precisely control the maximum number of vcpus their precious VMs > > > can use. > > > > > > The actual control itself must be done via the TDH.MNG.INIT SEAMCALL itself, > > > where the number of maximum cpus is an input to the TDX module, but KVM > > > needs to support the "per-VM number of maximum vcpus" and reflect that in > > per-VM maximum number of vcpus > > > the KVM_CAP_MAX_VCPUS. > > > > > > Currently, the KVM x86 always reports KVM_MAX_VCPUS for all VMs but doesn't > > > allow to enable KVM_CAP_MAX_VCPUS to configure the number of maximum vcpus > > maximum number of vcpus > > > on VM-basis. > > > > > > Add "per-VM maximum vcpus" to KVM x86/TDX to accommodate TDX's needs. > > > > > > The userspace-configured value then can be verified when KVM is actually > > used > > Here, "verified", I think Kai wanted to emphasize that the value of > max_vcpus passed in via > KVM_TDX_INIT_VM should be checked against the value configured via > KVM_CAP_MAX_VCPUS? > > Maybe "verified and used" ? Ok. I don't have strong opinion here. -- Isaku Yamahata <isaku.yamahata@xxxxxxxxx>
