On Mon, Jun 19, 2023 at 1:11 PM Zhi Wang <zhi.wang.linux@xxxxxxxxx> wrote: > > On Mon, 19 Jun 2023 12:11:50 -0700 > Vishal Annapurve <vannapurve@xxxxxxxxxx> wrote: > > > On Thu, Jun 15, 2023 at 1:12___PM <isaku.yamahata@xxxxxxxxx> wrote: > > > ... > > > > > > * VM type: Now we have KVM_X86_PROTECTED_VM. How do we proceed? > > > - Keep KVM_X86_PROTECTED_VM for its use. Introduce KVM_X86_TDX_VM > > > - Use KVM_X86_PROTECTED_VM for TDX. (If necessary, introduce another type in > > > the future) > > > - any other way? > > > > There are selftests posted[1] in context of this work, which rely on > > KVM_X86_PROTECTED_VM being just the software-only psuedo-confidential > > VMs. In future there might be more work to expand this usecase to > > full-scale VMs. So it would be better to treat protected VMs as a > > separate type which can be used on any platform without the need of > > enabling TDX/SEV functionality. > > > > Out of curiosity, is this really a valid case in practice except selftest? > It sounds to me whenever KVM_X86_PROTECTED_VM is used, it has to be tied > with a platform-specific CC type. Protected VM effort is about being able to have guest memory ranges not mapped into Userspace VMM and so are unreachable for most of the cases from KVM as well. Non-CC VMs can use this support to mitigate any unintended accesses from userspace VMM/KVM possibly using enlightened kernels. Exact implementation of such a support warrants more discussion but it should be in the line of sight here as a future work item. > > > TDX VM type can possibly serve as a specialized type of protected VM > > with additional arch specific capabilities enabled. > > > > [1] - https://github.com/sean-jc/linux/commits/x86/kvm_gmem_solo >
