> -----Original Message----- > From: Erdem Aktas <erdemaktas@xxxxxxxxxx> > Sent: Tuesday, July 27, 2021 2:38 AM > To: linux-kselftest@xxxxxxxxxxxxxxx > Cc: erdemaktas@xxxxxxxxxx; Paolo Bonzini <pbonzini@xxxxxxxxxx>; Shuah > Khan <shuah@xxxxxxxxxx>; Andrew Jones <drjones@xxxxxxxxxx>; Ben > Gardon <bgardon@xxxxxxxxxx>; Peter Xu <peterx@xxxxxxxxxx>; Sean > Christopherson <seanjc@xxxxxxxxxx>; Christian Borntraeger > <borntraeger@xxxxxxxxxx>; Eric Auger <eric.auger@xxxxxxxxxx>; > Emanuele Giuseppe Esposito <eesposit@xxxxxxxxxx>; Ricardo Koller > <ricarkol@xxxxxxxxxx>; Duan, Zhenzhong <zhenzhong.duan@xxxxxxxxx>; > Aaron Lewis <aaronlewis@xxxxxxxxxx>; Jim Mattson > <jmattson@xxxxxxxxxx>; Oliver Upton <oupton@xxxxxxxxxx>; Vitaly > Kuznetsov <vkuznets@xxxxxxxxxx>; Peter Shier <pshier@xxxxxxxxxx>; Axel > Rasmussen <axelrasmussen@xxxxxxxxxx>; Yanan Wang > <wangyanan55@xxxxxxxxxx>; Maciej S. Szmigiero > <maciej.szmigiero@xxxxxxxxxx>; David Matlack <dmatlack@xxxxxxxxxx>; > Like Xu <like.xu@xxxxxxxxxxxxxxx>; open list <linux-kernel@xxxxxxxxxxxxxxx>; > open list:KERNEL VIRTUAL MACHINE (KVM) <kvm@xxxxxxxxxxxxxxx> > 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@xxxxxxxxxx) > > 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@xxxxxxxxx> Regards Zhenzhong
