| Message ID | 20210726183816.1343022-1-erdemaktas@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | TDX KVM selftests | expand |
> -----Original Message----- > From: Erdem Aktas <erdemaktas@google.com> > Sent: Tuesday, July 27, 2021 2:38 AM > To: linux-kselftest@vger.kernel.org > Cc: erdemaktas@google.com; Paolo Bonzini <pbonzini@redhat.com>; Shuah > Khan <shuah@kernel.org>; Andrew Jones <drjones@redhat.com>; Ben > Gardon <bgardon@google.com>; Peter Xu <peterx@redhat.com>; Sean > Christopherson <seanjc@google.com>; Christian Borntraeger > <borntraeger@de.ibm.com>; Eric Auger <eric.auger@redhat.com>; > Emanuele Giuseppe Esposito <eesposit@redhat.com>; Ricardo Koller > <ricarkol@google.com>; Duan, Zhenzhong <zhenzhong.duan@intel.com>; > Aaron Lewis <aaronlewis@google.com>; Jim Mattson > <jmattson@google.com>; Oliver Upton <oupton@google.com>; Vitaly > Kuznetsov <vkuznets@redhat.com>; Peter Shier <pshier@google.com>; Axel > Rasmussen <axelrasmussen@google.com>; Yanan Wang > <wangyanan55@huawei.com>; Maciej S. Szmigiero > <maciej.szmigiero@oracle.com>; David Matlack <dmatlack@google.com>; > Like Xu <like.xu@linux.intel.com>; open list <linux-kernel@vger.kernel.org>; > open list:KERNEL VIRTUAL MACHINE (KVM) <kvm@vger.kernel.org> > Subject: [RFC PATCH 0/4] TDX KVM selftests > > TDX stands for Trust Domain Extensions which isolates VMs from the virtual- > machine manager (VMM)/hypervisor and any other software on the > platform. > > Intel has recently submitted a set of RFC patches for KVM support for TDX > and more information can be found on the latest TDX Support > Patches: https://lkml.org/lkml/2021/7/2/558 > > Due to the nature of the confidential computing environment that TDX > provides, it is very difficult to verify/test the KVM support. TDX requires UEFI > and the guest kernel to be enlightened which are all under development. > > We are working on a set of selftests to close this gap and be able to verify the > KVM functionality to support TDX lifecycle and GHCI [1] interface. > > We are looking for any feedback on: > - Patch series itself > - Any suggestion on how we should approach testing TDX functionality. > Does selftests seems reasonable or should we switch to using KVM unit tests. > I would be happy to get some perspective on how KVM unit tests can help us > more. > - Any test case or scenario that we should add. > - Anything else I have not thought of yet. > > Current patch series provide the following capabilities: > > - Provide helper functions to create a TD (Trusted Domain) using the KVM > ioctls > - Provide helper functions to create a guest image that can include any > testing code > - Provide helper functions and wrapper functions to write testing code > using GHCI interface > - Add a test case that verifies TDX life cycle > - Add a test case that verifies TDX GHCI port IO > > TODOs: > - Use existing function to create page tables dynamically > (ie __virt_pg_map()) > - Remove arbitrary defined magic numbers for data structure offsets > - Add TDVMCALL for error reporting > - Add additional test cases as some listed below > - Add #VE handlers to help testing more complicated test cases > > Other test cases that we are planning to add: > (with credit to sagis@google.com) > > VM call interface Input Output Result > GetTdVmCallInfo R12=0 None VMCALL_SUCCESS > MapGPA Map private page (GPA.S=0) > VMCALL_SUCCESS > MapGPA Map shared page (GPA.S=1) > VMCALL_SUCCESS > MapGPA Map already private page as private > VMCALL_INVALID_OPERAND > MapGPA Map already shared page as shared > VMCALL_INVALID_OPERAND > GetQuote > ReportFatalError > SetupEventNotifyInterrupt Valid interrupt value (32:255) > VMCALL_SUCCESS > SetupEventNotifyInterrupt Invalid value (>255) > VMCALL_INVALID_OPERAND > Instruction.CPUID R12(EAX)=1, R13(ECX)=0 EBX[8:15]=0x8 > EBX[16:23]=X > EBX[24:31]=vcpu_id > ECX[0]=1 > ECX[12]=Y > Instruction.CPUID R12(EAX)=1, R13(ECX)=4 > VMCALL_INVALID_OPERAND > VE.RequestMMIO > Instruction.HLT VMCALL_SUCCESS > Instruction.IO Read/Write 1/2/4 bytes VMCALL_SUCCESS > Instruction.IO Read/Write 3 bytes > VMCALL_INVALID_OPERAND > Instruction.RDMSR Accessible register R11=msr_value > VMCALL_SUCCESS > Inaccessible register > VMCALL_INVALID_OPERAND > Instruction.RDMSR Accessible register VMCALL_SUCCESS > Inaccessible register > VMCALL_INVALID_OPERAND > INSTRUCTION.PCONFIG > > [1] Intel TDX Guest-Hypervisor Communication Interface > > https://software.intel.com/content/dam/develop/external/us/en/document > s/intel-tdx-guest-hypervisor-communication-interface.pdf > > > Erdem Aktas (4): > KVM: selftests: Add support for creating non-default type VMs > KVM: selftest: Add helper functions to create TDX VMs In tools/testing/selftests/kvm/Makefile, '/lib/x86_64/tdx_lib.c' should be changed to 'lib/x86_64/tdx_lib.c' After that, build and test passes. # ./tdx_vm_tests Verifying TD lifecycle: Verifying TD IO Exit: ... IO WRITE: OK ... IO READ: OK ... IO verify read/write values: OK Tested-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Regards Zhenzhong
TDX stands for Trust Domain Extensions which isolates VMs from the virtual-machine manager (VMM)/hypervisor and any other software on the platform. Intel has recently submitted a set of RFC patches for KVM support for TDX and more information can be found on the latest TDX Support Patches: https://lkml.org/lkml/2021/7/2/558 Due to the nature of the confidential computing environment that TDX provides, it is very difficult to verify/test the KVM support. TDX requires UEFI and the guest kernel to be enlightened which are all under development. We are working on a set of selftests to close this gap and be able to verify the KVM functionality to support TDX lifecycle and GHCI [1] interface. We are looking for any feedback on: - Patch series itself - Any suggestion on how we should approach testing TDX functionality. Does selftests seems reasonable or should we switch to using KVM unit tests. I would be happy to get some perspective on how KVM unit tests can help us more. - Any test case or scenario that we should add. - Anything else I have not thought of yet. Current patch series provide the following capabilities: - Provide helper functions to create a TD (Trusted Domain) using the KVM ioctls - Provide helper functions to create a guest image that can include any testing code - Provide helper functions and wrapper functions to write testing code using GHCI interface - Add a test case that verifies TDX life cycle - Add a test case that verifies TDX GHCI port IO TODOs: - Use existing function to create page tables dynamically (ie __virt_pg_map()) - Remove arbitrary defined magic numbers for data structure offsets - Add TDVMCALL for error reporting - Add additional test cases as some listed below - Add #VE handlers to help testing more complicated test cases Other test cases that we are planning to add: (with credit to sagis@google.com) VM call interface Input Output Result GetTdVmCallInfo R12=0 None VMCALL_SUCCESS MapGPA Map private page (GPA.S=0) VMCALL_SUCCESS MapGPA Map shared page (GPA.S=1) VMCALL_SUCCESS MapGPA Map already private page as private VMCALL_INVALID_OPERAND MapGPA Map already shared page as shared VMCALL_INVALID_OPERAND GetQuote ReportFatalError SetupEventNotifyInterrupt Valid interrupt value (32:255) VMCALL_SUCCESS SetupEventNotifyInterrupt Invalid value (>255) VMCALL_INVALID_OPERAND Instruction.CPUID R12(EAX)=1, R13(ECX)=0 EBX[8:15]=0x8 EBX[16:23]=X EBX[24:31]=vcpu_id ECX[0]=1 ECX[12]=Y Instruction.CPUID R12(EAX)=1, R13(ECX)=4 VMCALL_INVALID_OPERAND VE.RequestMMIO Instruction.HLT VMCALL_SUCCESS Instruction.IO Read/Write 1/2/4 bytes VMCALL_SUCCESS Instruction.IO Read/Write 3 bytes VMCALL_INVALID_OPERAND Instruction.RDMSR Accessible register R11=msr_value VMCALL_SUCCESS Inaccessible register VMCALL_INVALID_OPERAND Instruction.RDMSR Accessible register VMCALL_SUCCESS Inaccessible register VMCALL_INVALID_OPERAND INSTRUCTION.PCONFIG [1] Intel TDX Guest-Hypervisor Communication Interface https://software.intel.com/content/dam/develop/external/us/en/documents/intel-tdx-guest-hypervisor-communication-interface.pdf Erdem Aktas (4): KVM: selftests: Add support for creating non-default type VMs KVM: selftest: Add helper functions to create TDX VMs KVM: selftest: Adding TDX life cycle test. KVM: selftest: Adding test case for TDX port IO tools/testing/selftests/kvm/Makefile | 6 +- .../testing/selftests/kvm/include/kvm_util.h | 1 + .../selftests/kvm/include/x86_64/processor.h | 5 + tools/testing/selftests/kvm/lib/kvm_util.c | 29 +- .../selftests/kvm/lib/x86_64/processor.c | 23 ++ tools/testing/selftests/kvm/lib/x86_64/tdx.h | 220 ++++++++++++ .../selftests/kvm/lib/x86_64/tdx_lib.c | 314 ++++++++++++++++++ .../selftests/kvm/x86_64/tdx_vm_tests.c | 209 ++++++++++++ 8 files changed, 800 insertions(+), 7 deletions(-) create mode 100644 tools/testing/selftests/kvm/lib/x86_64/tdx.h create mode 100644 tools/testing/selftests/kvm/lib/x86_64/tdx_lib.c create mode 100644 tools/testing/selftests/kvm/x86_64/tdx_vm_tests.c