linux-kernel - Re: [PATCH v19 037/130] KVM: 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: <fde1729f-aca7-4cf8-a2cb-a7fde5b4f936@linux.intel.com>
Date: Mon, 25 Mar 2024 16:42:36 +0800
From: Binbin Wu <binbin.wu@...ux.intel.com>
To: Isaku Yamahata <isaku.yamahata@...el.com>,
 "Huang, Kai" <kai.huang@...el.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
 isaku.yamahata@...il.com, Paolo Bonzini <pbonzini@...hat.com>,
 erdemaktas@...gle.com, Sean Christopherson <seanjc@...gle.com>,
 Sagi Shahar <sagis@...gle.com>, chen.bo@...el.com, hang.yuan@...el.com,
 tina.zhang@...el.com, isaku.yamahata@...ux.intel.com
Subject: Re: [PATCH v19 037/130] KVM: TDX: Make KVM_CAP_MAX_VCPUS backend
 specific



On 3/23/2024 9:13 AM, Isaku Yamahata wrote:
> On Fri, Mar 22, 2024 at 12:36:40PM +1300,
> "Huang, Kai" <kai.huang@...el.com> 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" ?

>> creating the TDX guest.
>> "
>