On 4/2/2022 4:18 AM, Isaku Yamahata wrote:
On Fri, Apr 01, 2022 at 02:56:40PM +0800,
Xiaoyao Li <xiaoyao.li@xxxxxxxxx> wrote:
On 4/1/2022 3:41 AM, Isaku Yamahata wrote:
On Thu, Mar 31, 2022 at 04:31:10PM +1300,
Kai Huang <kai.huang@xxxxxxxxx> wrote:
On Fri, 2022-03-04 at 11:48 -0800, isaku.yamahata@xxxxxxxxx wrote:
From: Isaku Yamahata <isaku.yamahata@xxxxxxxxx>
Add a wrapper function to initialize the TDX module and get system-wide
parameters via those APIs. Because TDX requires VMX enabled, It will be
called on-demand when the first guest TD is created via x86 KVM init_vm
callback.
Why not just merge this patch with the change where you implement the init_vm
callback? Then you can just declare this patch as "detect and initialize TDX
module when first VM is created", or something like that..
Ok. Anyway in the next respoin, tdx module initialization will be done when
loading kvm_intel.ko. So the whole part will be changed and will be a part
of module loading.
Will we change the GET_TDX_CAPABILITIES ioctl back to KVM scope?
No because it system scoped KVM_TDX_CAPABILITIES requires one more callback for
it. We can reduce the change.
Or do you have any use case for system scoped KVM_TDX_CAPABILITIES?
No. Just to confirm.
on the other hand, vm-scope IOCTL seems more flexible if different
capabilities are reported per VM in the future.
