Re: [RFC PATCH v3 00/59] KVM: X86: TDX support

Kai Huang
2021-12-01T20:28:48Z

>
> > Anyway The plan is what Kai said. The code will reside in the x86 common
> > directory instead of kvm.
>
> But what's the plan at a higher level? Will the kernel load the ACM or is that
> done by firmware? If it's done by firmware, which entity is responsibile for
> loading the TDX module? If firmware loads the module, what's the plan for
> upgrading the module without a reboot? When will the kernel initialize the
> module, regardless of who loads it?

The UEFI loads both ACM and TDX module before booting into kernel by using UEFI
tool. The runtime update is pushed out for future support. One goal of
this is to reduce the code size so that it can be reviewed more easily and
quickly.

And yes kernel will initialize the TDX module. The direction we are heading is
to allow to defer TDX module initialization when TDX is truly needed, i.e.
When KVM is loaded with TDX support, or first TD is created. The code will
basically still reside in host kernel, provided as functions, etc. And at first
stage, KVM will call those functions to initialize TDX when needed.

The advantage of this approach is it provides more flexibility: the TDX module
initialization code can be reused by future TDX runtime update, etc. And with
only initializing TDX in KVM, the host kernel doesn't need to handle entering
VMX operation, etc. It can be introduced later when needed.

>
> All of those unanswered questions make it nigh impossible to review the KVM
> support because the code organization and APIs provided will differ based on how
> the kernel handles loading and initializing the TDX module.

I think theoretically loading/initializing module should be quite independent
from KVM series, but yes in practice the APIs matter, but I also don't expect
this will reduce the ability to review KVM series a lot as RFC.

Anyway sending out host kernel patches is our top priority now and we are
trying to do asap.