On Sun, Feb 04, 2024 at 10:00:45AM +0800, Binbin Wu <binbin.wu@xxxxxxxxxxxxxxx> wrote: > > > On 2/1/2024 2:16 PM, Yuan Yao wrote: > > On Wed, Jan 24, 2024 at 09:17:15AM +0800, Binbin Wu wrote: > > > > > > On 1/23/2024 7:52 AM, isaku.yamahata@xxxxxxxxx wrote: > > > > From: Isaku Yamahata <isaku.yamahata@xxxxxxxxx> > > > > > > > > TDX has its own limitation on the maximum number of vcpus that the guest > > > > can accommodate. Allow x86 kvm backend to implement its own KVM_ENABLE_CAP > > > > handler and implement TDX backend for KVM_CAP_MAX_VCPUS. user space VMM, > > > > e.g. qemu, can specify its value instead of KVM_MAX_VCPUS. > > > For legacy VM, KVM just provides the interface to query the max_vcpus. > > > Why TD needs to provide a interface for userspace to set the limitation? > > > What's the scenario? > > I think the reason is TDH.MNG.INIT needs it: > > > > TD_PARAMS: > > MAX_VCPUS: > > offset: 16 bytes. > > type: Unsigned 16b Integer. > > size: 2. > > Description: Maximum number of VCPUs. > Thanks for explanation. > > I am also wondering if this info can be passed via KVM_TDX_INIT_VM. > Because userspace is allowed to set the value no greater than > min(KVM_MAX_VCPUS, TDX_MAX_VCPUS), providing the extra cap KVM_CAP_MAX_VCPUS > doesn't make more restriction comparing to providing it in KVM_TDX_INIT_VM. It's better for the API to be common, not specific to TDX. Also I don't want to play with max_vcpu in multiple places. -- Isaku Yamahata <isaku.yamahata@xxxxxxxxxxxxxxx>
