lkml.org 
[lkml]   [2023]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v13 018/113] KVM: x86, tdx: Make KVM_CAP_MAX_VCPUS backend specific
    On Wed, 29 Mar 2023 16:32:58 -0700
    Isaku Yamahata <isaku.yamahata@gmail.com> wrote:

    > On Sat, Mar 25, 2023 at 08:13:26PM +0200,
    > Zhi Wang <zhi.wang.linux@gmail.com> wrote:
    >
    > > On Sun, 12 Mar 2023 10:55:42 -0700
    > > isaku.yamahata@intel.com wrote:
    > >
    > > > From: Isaku Yamahata <isaku.yamahata@intel.com>
    > > >
    > > > 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.
    > > >
    > >
    > > I think enabling the cap here is actually "configuring the cap". KVM_CAP_MAX
    > > _VCPUS is actually always enabled whether userspace enables it or not. It
    > > would be nice to configure of the max VCPUS in kvm_arch_vm_ioctl() where
    > > routines of configuring a VM should belong. E.g. KVM_SET_MAX_VCPUS.
    >
    > I'm not sure I understand your point. Although KVM_ENABLE_CAP sounds like
    > only on/off feature, but it isn't. It's also used to set parameters. For
    > example, KVM_CAP_MAX_VCPU_ID.
    >

    Yes, I understand your point. But what has been there might not be right as
    well. That doesn't smell right as "enable" is for something which is previously
    "disabled". I understand that there can be some caps require configuration
    when being enabled. But later, for those caps which don't have "on/off"
    state, KVM_ENABLE_CAP doesn't actually enable a feature, it is just
    configuring a feature. It seems like the KVM_ENABLE_CAP has been mis-used
    little by little in the history. Also, I don't find KVM_DISABLE_CAP
    accordingly. So KVM_ENABLE_CAP is actually used as "KVM_SET_CAP".

    I realize it is not realistic to solve the problem in this patch series.
    You can keep the current approach.

    > KVM_SET_XXX is for run time feature. But the maxium number of vcpus is not
    > runtime changable. Set it at vm creation.

    \
     
     \ /
      Last update: 2023-04-01 09:01    [W:4.100 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site