linux-kernel - Re: [PATCH v13 018/113] KVM: x86, tdx: Make KVM_CAP_MAX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230401100040.0000515c@gmail.com>
Date:   Sat, 1 Apr 2023 10:00:40 +0300
From:   Zhi Wang <zhi.wang.linux@...il.com>
To:     Isaku Yamahata <isaku.yamahata@...il.com>
Cc:     isaku.yamahata@...el.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
        erdemaktas@...gle.com, Sean Christopherson <seanjc@...gle.com>,
        Sagi Shahar <sagis@...gle.com>,
        David Matlack <dmatlack@...gle.com>,
        Kai Huang <kai.huang@...el.com>
Subject: Re: [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@...il.com> wrote:

> On Sat, Mar 25, 2023 at 08:13:26PM +0200,
> Zhi Wang <zhi.wang.linux@...il.com> wrote:
> 
> > On Sun, 12 Mar 2023 10:55:42 -0700
> > isaku.yamahata@...el.com wrote:
> > 
> > > From: Isaku Yamahata <isaku.yamahata@...el.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.