On Mon, 19 Jun 2023 14:55:09 -0700 Vishal Annapurve <vannapurve@xxxxxxxxxx> wrote: > 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. > > IIUC, what you are saying is (KVM_X86_PROTECTED_VM == (VMs with UPM or GMEM)) && (KVM_X86_PROTECTED_VM != KVM_X86_CC_VM) && KVM_X86_CC_VM requires KVM_X86_PROTECTED_VM. If we think KVM_X86_PROTECTED_VM as a dedicated feature, not tightly coupled with CC techs, it seems we needs another defination of KVM_X86_CC_VM to represent CC VM and CC platform types like KVM_X86_CC_TDX_VM to tell which CC tech sits behind it? I don't think it is good to mix the usages of KVM_X86_PROTECTED_VM and KVM_X86_CC_VM together if we are sure KVM_X86_PROTECTED_VM is not going to represent CC VMs in the code. > > > > > > > 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 > >
