[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17981a2e-03e3-81df-0654-5ccb29f43546@intel.com>
Date: Wed, 6 Apr 2022 09:54:05 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Paolo Bonzini <pbonzini@...hat.com>, isaku.yamahata@...el.com,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: isaku.yamahata@...il.com, Jim Mattson <jmattson@...gle.com>,
erdemaktas@...gle.com, Connor Kuehl <ckuehl@...hat.com>,
Sean Christopherson <seanjc@...gle.com>
Subject: Re: [RFC PATCH v5 026/104] KVM: TDX: x86: Add vm ioctl to get TDX
systemwide parameters
On 4/5/2022 8:52 PM, Paolo Bonzini wrote:
> On 3/4/22 20:48, isaku.yamahata@...el.com wrote:
>> Implement a VM-scoped subcomment to get system-wide parameters. Although
>> this is system-wide parameters not per-VM, this subcomand is VM-scoped
>> because
>> - Device model needs TDX system-wide parameters after creating KVM VM.
>> - This subcommands requires to initialize TDX module. For lazy
>> initialization of the TDX module, vm-scope ioctl is better.
>
> Since there was agreement to install the TDX module on load, please
> place this ioctl on the /dev/kvm file descriptor.
>
> At least for SEV, there were cases where the system-wide parameters are
> needed outside KVM, so it's better to avoid requiring a VM file descriptor.
I don't have strong preference on KVM-scope ioctl or VM-scope.
Initially, we made it KVM-scope and change it to VM-scope in this
version. Yes, it returns the info from TDX module, which doesn't vary
per VM. However, what if we want to return different capabilities
(software controlled capabilities) per VM? Part of the TDX capabilities
serves like get_supported_cpuid, making it KVM wide lacks the
flexibility to return differentiated capabilities for different TDs.
> Thanks,
>
> Paolo
>
Powered by blists - more mailing lists