KVM TDX: preparation for coexistence of VMX and TDX
Subsystems (5)
v4 cover KVM TDX: preparation for coexistence of VMX and TDX
From: Isaku Yamahata <[email protected]>
* What's TDX?
TDX stands for Trust Domain Extensions, which extends Intel Virtual Machines Extensions (VMX) to introduce a kind of virtual machine guest called a Trust Domain (TD) for confidential computing.
A TD runs in a CPU mode that is designed to protect the confidentiality of its memory contents and its CPU state from any other software, including the hosting Virtual Machine Monitor (VMM), unless explicitly shared by the TD itself.
We have more detailed explanations below (***). We have the high-level design of TDX KVM below (****).
In this patch series, we use "TD" or "guest TD" to differentiate it from the current "VM" (Virtual Machine), which is supported by KVM today.
* This patch series and whole patches
Because it needs more than 90 patches for KVM to run guest TDs, the patches are split into layers of patch series so that we can build the TDX code structure in KVM step by step. We believe that this should make the review process efficient and effective.
All of the patches (not just this patch series) are available at
https://github.com/intel/tdx/releases/tag/kvm-upstream-2022.02.18-v5.17-rc4.
The corresponding patches to qemu are available at
https://github.com/intel/qemu-tdx/commits/tdx-upstream.
The relations of the layers are depicted as follows.
The arrows below show the order of patch reviews we would like to have.
TDX vcpu
interrupt/exits/hypercall<------------\
^ |
| |
TDX EPT violation<------------\ |
^ | |
| | |
TD vcpu enter/exit | |
^ | |
| | |
TD vcpu creation/destruction | \-------KVM TDP MMU MapGPA
^ | ^
| | |
TD VM creation/destruction \---------------KVM TDP MMU hooks
^ ^
| |
TDX architectural definitions KVM TDP refactoring for TDX
^ ^
| |
+-----------+ |
|TDX, VMX |<--------TDX module KVM MMU GPA stolen bits
|coexistence| initialization
+-----------+ focus of this
patch series
The above layers are chosen so that the device model, for example, qemu can exercise each layering step by step. Check if TDX is supported, create TD VM, create TD vcpu, allow vcpu running, populate TD guest private memory, and handle vcpu exits/hypercalls/interrupts to run TD fully.
The followings are explanations of each layer.
TDX module initialization:
The guts of system-wide initialization of TDX module. There is an independent patch series for host x86. TDX KVM patches call functions this patch series provides to initialize the TDX module. This patch series starts with "[MARKER] The start of TDX host patch series".
TDX, VMX coexistence:
Infrastructure to allow TDX to coexist with VMX and trigger the initialization of the TDX module.
This patch series starts with "[MARKER] The start of TDX KVM patch
series: TDX, VMX coexistence".
TDX architectural definitions:
Add TDX architectural definitions and helper functions
This patch series starts with "[MARKER] The start of TDX KVM patch
series: TDX architectural definitions".
TD VM creation/destruction:
Guest TD creation/destroy allocation and releasing of TDX specific vm and vcpu structure. Create an initial guest memory image with TDX measurement.
This patch series starts with "[MARKER] The start of TDX KVM patch
series: TD VM creation/destruction" and "[MARKER] The start of TDX KVM patch series: TD finalization".
TD vcpu creation/destruction:
guest TD creation/destroy Allocation and releasing of TDX specific vm and vcpu structure. Create an initial guest memory image with TDX measurement.
This patch series starts with "[MARKER] The start of TDX KVM patch
series: TD vcpu creation/destruction".
TDX EPT violation:
Create an initial guest memory image with TDX measurement. Handle secure EPT violations to populate guest pages with TDX SEAMCALLs. This patch series starts with "[MARKER] The start of TDX KVM patch
series: TDX EPT violation".
TD vcpu enter/exit:
Allow TDX vcpu to enter into TD and exit from TD. Save CPU state before entering into TD. Restore CPU state after exiting from TD. This patch series starts with "[MARKER] The start of TDX KVM patch
series: TD vcpu enter/exit".
TD vcpu interrupts/exit/hypercall:
Handle various exits/hypercalls and allow interrupts to be injected so that TD vcpu can continue running.
This patch series starts with "[MARKER] The start of TDX KVM patch
series: TD vcpu exits/interrupts/hypercalls".
KVM MMU GPA stolen bits:
Introduce framework to handle stolen repurposed bit of GPA TDX repurposed a bit of GPA to indicate shared or private. If it's shared, it's the same as the conventional VMX EPT case. VMM can access shared guest pages. If it's private, it's handled by Secure-EPT and the guest page is encrypted.
This patch series starts with "[MARKER] The start of TDX KVM patch
series: KVM MMU GPA stolen bits".
KVM TDP refactoring for TDX:
TDX Secure EPT requires different constants. e.g. initial value EPT entry value etc. Various refactoring for those differences. This patch series starts with "[MARKER] The start of TDX KVM patch
series: KVM TDP refactoring for TDX".
KVM TDP MMU hooks:
Introduce framework to TDP MMU to add hooks in addition to direct EPT access TDX added Secure EPT which is an enhancement to VMX EPT. Unlike conventional VMX EPT, CPU can't directly read/write Secure EPT. Instead, use TDX SEAMCALLs to operate on Secure EPT.
This patch series starts with "[MARKER] The start of TDX KVM patch
series: KVM TDP MMU hooks".
KVM TDP MMU MapGPA:
Introduce framework to handle switching guest pages from private/shared to shared/private. For a given GPA, a guest page can be assigned to a private GPA or a shared GPA exclusively. With TDX MapGPA hypercall, guest TD converts GPA assignments from private (or shared) to shared (or private).
This patch series starts with "[MARKER] The start of TDX KVM patch
series: KVM TDP MMU MapGPA".
KVM guest private memory: (not shown in the above diagram)
[PATCH v4 00/12] KVM: mm: fd-based approach for supporting KVM guest private
memory: https://lkml.org/lkml/2022/1/18/395
Guest private memory requires different memory management in KVM. The patch proposes a way for it. Integration with TDX KVM.
* The focus of this patch series
This patch series implements the infrastructure for KVM to 1) allow the coexistence of VMX and TDX, and 2) start the initialization of the TDX module for KVM to use the TDX module API.
1) Existing VMs (VMX VMs) and TDs can run on the same physical machine simultaneously. Today, we need two kernel modules for VMX: the common x86 KVM module (kvm.ko) and the VMX-specific module (kvm_intel.ko) that implements the VMX-specific operations as "callbacks". We need different operations for TDs and part of them can be shared, depending on the operation. Because the x86 KVM operations are global, i.e. not per-VM in KVM, we think that the most reasonable way for adding TDX support would be to have the common entry points for the callbacks like:
"if (is_td_vcpu(vcpu)) tdx_callback() else vmx_callback();"
to allow VMX and TDX to coexist, handled in the same VMX/TDX-specific module (kvm_intel.ko). It builds a foundation so that the rest of the TDX patches can add TDX specific code without affecting the existing VMX code.
2) For initialization (and de-initialization), we refactor the VMX initialization flow and put TDX initialization hooks. As the TDX technology is built on top of VMX, the system-wide initialization of the TDX Module (below) is required to run guest TDs in addition to conventional VMX initialization.
With this patch series applied, we can confirm that
a) we can create/run/destroy the existing VMs (VMX VM) normally. The existing VMX code is intact.
b) we can enable TDX module initialization by integrating with the TDX host patch series. The device model, for example, qemu can initiate the creation of a guest TD. If the TDX module is not available, it will fail. If the TDX module is available, initialize the TDX module and then fail.
(***)
* TDX module
A CPU-attested software module called the "TDX module" is designed to implement the TDX architecture, and it is loaded by the UEFI firmware today. It can be loaded by the kernel or driver at runtime, but in this patch series we assume that the TDX module is already loaded and initialized.
The TDX module provides two main new logical modes of operation built upon the new SEAM (Secure Arbitration Mode) root and non-root CPU modes added to the VMX architecture. TDX root mode is mostly identical to the VMX root operation mode, and the TDX functions (described later) are triggered by the new SEAMCALL instruction with the desired interface function selected by an input operand (leaf number, in RAX). TDX non-root mode is used for TD guest operation. TDX non-root operation (i.e. "guest TD" mode) is similar to the VMX non-root operation (i.e. guest VM), with changes and restrictions to better assure that no other software or hardware has direct visibility of the TD memory and state.
TDX transitions between TDX root operation and TDX non-root operation include TD Entries, from TDX root to TDX non-root mode, and TD Exits from TDX non-root to TDX root mode. A TD Exit might be asynchronous, triggered by some external event (e.g., external interrupt or SMI) or an exception, or it might be synchronous, triggered by a TDCALL (TDG.VP.VMCALL) function.
TD VCPUs can be entered using SEAMCALL(TDH.VP.ENTER) by KVM. TDH.VP.ENTER is one of the TDX interface functions as mentioned above, and "TDH" stands for Trust Domain Host. Those host-side TDX interface functions are categorized into various areas just for better organization, such as SYS (TDX module management), MNG (TD management), VP (VCPU), PHYSMEM (physical memory), MEM (private memory), etc. For example, SEAMCALL(TDH.SYS.INFO) returns the TDX module information.
TDCS (Trust Domain Control Structure) is the main control structure of a guest TD, and encrypted (using the guest TD's ephemeral private key). At a high level, TDCS holds information for controlling TD operation as a whole, execution, EPTP, MSR bitmaps, etc that KVM needs to set it up. Note that MSR bitmaps are held as part of TDCS (unlike VMX) because they are meant to have the same value for all VCPUs of the same TD.
Trust Domain Virtual Processor State (TDVPS) is the root control structure of a TD VCPU. It helps the TDX module control the operation of the VCPU, and holds the VCPU state while the VCPU is not running. TDVPS is opaque to software and DMA access, accessible only by using the TDX module interface functions (such as TDH.VP.RD, TDH.VP.WR). TDVPS includes TD VMCS, and TD VMCS auxiliary structures, such as virtual APIC page, virtualization exception information, etc.
Several VMX control structures (such as Shared EPT and Posted interrupt descriptor) are directly managed and accessed by the host VMM. These control structures are pointed to by fields in the TD VMCS.
The above means that 1) KVM needs to allocate different data structures for TDs,
2) KVM can reuse the existing code for TDs for some operations, 3) it needs to define TD-specific handling for others. 3) Redirect operations to . 3) Redirect operations to the TDX specific callbacks, like "if (is_td_vcpu(vcpu)) tdx_callback() else vmx_callback();".
*TD Private Memory
TD private memory is designed to hold TD private content, encrypted by the CPU using the TD ephemeral key. An encryption engine holds a table of encryption keys, and an encryption key is selected for each memory transaction based on a Host Key Identifier (HKID). By design, the host VMM does not have access to the encryption keys.
In the first generation of MKTME, HKID is "stolen" from the physical address by allocating a configurable number of bits from the top of the physical address. The HKID space is partitioned into shared HKIDs for legacy MKTME accesses and private HKIDs for SEAM-mode-only accesses. We use 0 for the shared HKID on the host so that MKTME can be opaque or bypassed on the host.
During TDX non-root operation (i.e. guest TD), memory accesses can be qualified as either shared or private, based on the value of a new SHARED bit in the Guest Physical Address (GPA). The CPU translates shared GPAs using the usual VMX EPT (Extended Page Table) or "Shared EPT" (in this document), which resides in host VMM memory. The Shared EPT is directly managed by the host VMM - the same as with the current VMX. Since guest TDs usually require I/O, and the data exchange needs to be done via shared memory, thus KVM needs to use the current EPT functionality even for TDs.
* Secure EPT and Minoring using the TDP code
The CPU translates private GPAs using a separate Secure EPT. The Secure EPT pages are encrypted and integrity-protected with the TD's ephemeral private key. Secure EPT can be managed _indirectly_ by the host VMM, using the TDX interface functions, and thus conceptually Secure EPT is a subset of EPT (why "subset"). Since execution of such interface functions takes much longer time than accessing memory directly, in KVM we use the existing TDP code to minor the Secure EPT for the TD.
This way, we can effectively walk Secure EPT without using the TDX interface functions.
* VM life cycle and TDX specific operations
The userspace VMM, such as QEMU, needs to build and treat TDs differently. For example, a TD needs to boot in private memory, and the host software cannot copy the initial image to private memory.
* TSC Virtualization
The TDX module helps TDs maintain reliable TSC (Time Stamp Counter) values (e.g. consistent among the TD VCPUs) and the virtual TSC frequency is determined by TD configuration, i.e. when the TD is created, not per VCPU. The current KVM owns TSC virtualization for VMs, but the TDX module does for TDs.
* MCE support for TDs
The TDX module doesn't allow VMM to inject MCE. Instead PV way is needed for TD to communicate with VMM. For now, KVM silently ignores MCE request by VMM. MSRs related to MCE (e.g, MCE bank registers) can be naturally emulated by paravirtualizing MSR access.
[1] For details, the specifications, [2], [3], [4], [5], [6], [7], are available.
* Restrictions or future work
Some features are not included to reduce patch size. Those features are addressed as future independent patch series.
- large page (2M, 1G)
- qemu gdb stub
- guest PMU
- and more
* Prerequisites
It's required to load the TDX module and initialize it. It's out of the scope of this patch series. Another independent patch for the common x86 code is planned. It defines CONFIG_INTEL_TDX_HOST and this patch series uses CONFIG_INTEL_TDX_HOST. It's assumed that With CONFIG_INTEL_TDX_HOST=y, the TDX module is initialized and ready for KVM to use the TDX module APIs for TDX guest life cycle like tdh.mng.init are ready to use.
Concretely Global initialization, LP (Logical Processor) initialization, global configuration, the key configuration, and TDMR and PAMT initialization are done. The state of the TDX module is SYS_READY. Please refer to the TDX module specification, the chapter Intel TDX Module Lifecycle State Machine
** Detecting the TDX module readiness.
TDX host patch series implements the detection of the TDX module availability and its initialization so that KVM can use it. Also it manages Host KeyID (HKID) assigned to guest TD.
The assumed APIs the TDX host patch series provides are
- int seamrr_enabled()
Check if required cpu feature (SEAM mode) is available. This only check CPU feature availability. At this point, the TDX module may not be ready for KVM to use.
- int init_tdx(void);
Initialization of TDX module so that the TDX module is ready for KVM to use.
- const struct tdsysinfo_struct *tdx_get_sysinfo(void);
Return the system wide information about the TDX module. NULL if the TDX isn't initialized.
- u32 tdx_get_global_keyid(void);
Return global key id that is used for the TDX module itself.
- int tdx_keyid_alloc(void);
Allocate HKID for guest TD.
- void tdx_keyid_free(int keyid);
Free HKID for guest TD.
(****)
* TDX KVM high-level design
- Host key ID management
Host Key ID (HKID) needs to be assigned to each TDX guest for memory encryption. It is assumed The TDX host patch series implements necessary functions, u32 tdx_get_global_keyid(void), int tdx_keyid_alloc(void) and,
void tdx_keyid_free(int keyid).
- Data structures and VM type
Because TDX is different from VMX, define its own VM/VCPU structures, struct kvm_tdx and struct vcpu_tdx instead of struct kvm_vmx and struct vcpu_vmx. To identify the VM, introduce VM-type to specify which VM type, VMX (default) or TDX, is used.
- VM life cycle and TDX specific operations
Re-purpose the existing KVM_MEMORY_ENCRYPT_OP to add TDX specific operations. New commands are used to get the TDX system parameters, set TDX specific VM/VCPU parameters, set initial guest memory and measurement.
The creation of TDX VM requires five additional operations in addition to the conventional VM creation.
- Get KVM system capability to check if TDX VM type is supported
- VM creation (KVM_CREATE_VM)
- New: Get the TDX specific system parameters. KVM_TDX_GET_CAPABILITY.
- New: Set TDX specific VM parameters. KVM_TDX_INIT_VM.
- VCPU creation (KVM_CREATE_VCPU)
- New: Set TDX specific VCPU parameters. KVM_TDX_INIT_VCPU.
- New: Initialize guest memory as boot state and extend the measurement with the memory. KVM_TDX_INIT_MEM_REGION.
- New: Finalize VM. KVM_TDX_FINALIZE. Complete measurement of the initial TDX VM contents.
- VCPU RUN (KVM_VCPU_RUN)
- Protected guest state
Because the guest state (CPU state and guest memory) is protected, the KVM VMM can't operate on them. For example, accessing CPU registers, injecting exceptions, and accessing guest memory. Those operations are handled as silently ignored, returning zero or initial reset value when it's requested via KVM API ioctls.
VM/VCPU state and callbacks for TDX specific operations. Define tdx specific VM state and VCPU state instead of VMX ones. Redirect operations to TDX specific callbacks. "if (tdx) tdx_op() else vmx_op()".
Operations on the CPU state
silently ignore operations on the guest state. For example, the write to CPU registers is ignored and the read from CPU registers returns 0.
. ignore access to CPU registers except for allowed ones.
. TSC: add a check if tsc is immutable and return an error. Because the KVM
implementation updates the internal tsc state and it's difficult to back out those changes. Instead, skip the logic.
. dirty logging: add check if dirty logging is supported.
. exceptions/SMI/MCE/SIPI/INIT: silently ignore
Note: virtual external interrupt and NMI can be injected into TDX guests.
- KVM MMU integration
One bit of the guest physical address (bit 51 or 47) is repurposed to indicate if the guest physical address is private (the bit is cleared) or shared (the bit is set). The bits are called stolen bits.
- Stolen bits framework
systematically tracks which guest physical address, shared or private, is used.
- Shared EPT and secure EPT
There are two EPTs. Shared EPT (the conventional one) and Secure EPT(the new one). Shared EPT is handled the same for the stolen bit set. Secure EPT points to private guest pages. To resolve EPT violation, KVM walks one of two EPTs based on faulted GPA. Because it's costly to access secure EPT during walking EPTs with SEAMCALLs for the private guest physical address, another private EPT is used as a shadow of Secure-EPT with the existing logic at the cost of extra memory.
The following depicts the relationship.
KVM | TDX module
| | |
-------------+---------- | |
| | | |
V V | |
shared GPA private GPA | |
CPU shared EPT pointer KVM private EPT pointer | CPU secure EPT pointer
| | | |
| | | |
V V | V
shared EPT private EPT<-------mirror----->Secure EPT
| | | |
| \--------------------+------\ |
| | | |
V | V V
shared guest page | private guest page
|
|
non-encrypted memory | encrypted memory
| - Operating on Secure EPT
Use the TDX module APIs to operate on Secure EPT. To call the TDX API during resolving EPT violation, add hooks to additional operation and wiring it to TDX backend.
* References
[1] TDX specification
https://software.intel.com/content/www/us/en/develop/articles/intel-trust-domain-extensions.html
[2] Intel Trust Domain Extensions (Intel TDX)
https://software.intel.com/content/dam/develop/external/us/en/documents/tdx-whitepaper-final9-17.pdf
[3] Intel CPU Architectural Extensions Specification
https://software.intel.com/content/dam/develop/external/us/en/documents-tps/intel-tdx-cpu-architectural-specification.pdf
[4] Intel TDX Module 1.0 EAS
https://software.intel.com/content/dam/develop/external/us/en/documents/tdx-module-1eas-v0.85.039.pdf
[5] Intel TDX Loader Interface Specification
https://software.intel.com/content/dam/develop/external/us/en/documents-tps/intel-tdx-seamldr-interface-specification.pdf
[6] Intel TDX Guest-Hypervisor Communication Interface
https://software.intel.com/content/dam/develop/external/us/en/documents/intel-tdx-guest-hypervisor-communication-interface.pdf
[7] Intel TDX Virtual Firmware Design Guide
https://software.intel.com/content/dam/develop/external/us/en/documents/tdx-virtual-firmware-design-guide-rev-1.pdf
[8] intel public github
kvm TDX branch: https://github.com/intel/tdx/tree/kvm
TDX guest branch: https://github.com/intel/tdx/tree/guest
qemu TDX https://github.com/intel/qemu-tdx
[9] TDVF
https://github.com/tianocore/edk2-staging/tree/TDVF
---
Changes from v4 internal review
- narrow the scope of patches for efficient review
- rebase to v5.17-rc
Changes from v3
- reorganize patch series for review.
- integrated updated vm_type patches
Changes from v2:
- update based on patch review
- support TDP MMU
- drop non-essential features (ftrace etc.) to reduce patch size
Changes from v1:
- rebase to v5.13
- drop load/initialization of TDX module
- catch up on the update of related specifications.
- rework on C-wrapper function to invoke seamcall
- various code clean up
Isaku Yamahata (5):
KVM: TDX: Detect CPU feature on kernel module initialization
KVM: x86: Refactor KVM VMX module init/exit functions
KVM: TDX: Add placeholders for TDX VM/vcpu structure
KVM: TDX: Add a function to initialize TDX module
KVM: TDX: Make TDX VM type supported
Sean Christopherson (3):
KVM: VMX: Move out vmx_x86_ops to 'main.c' to wrap VMX and TDX
KVM: Enable hardware before doing arch VM initialization
KVM: x86: Introduce vm_type to differentiate default VMs from
confidential VMs
Documentation/virt/kvm/api.rst | 15 + arch/x86/include/asm/kvm-x86-ops.h | 1 + arch/x86/include/asm/kvm_host.h | 2 + arch/x86/include/uapi/asm/kvm.h | 3 + arch/x86/kvm/Makefile | 3 +- arch/x86/kvm/svm/svm.c | 6 + arch/x86/kvm/vmx/main.c | 224 +++++++++++++ arch/x86/kvm/vmx/tdx.c | 218 +++++++++++++ arch/x86/kvm/vmx/tdx.h | 47 +++ arch/x86/kvm/vmx/vmx.c | 453 +++++++++----------------- arch/x86/kvm/vmx/x86_ops.h | 141 ++++++++ arch/x86/kvm/x86.c | 9 +- include/uapi/linux/kvm.h | 1 + tools/arch/x86/include/uapi/asm/kvm.h | 3 + tools/include/uapi/linux/kvm.h | 1 + virt/kvm/kvm_main.c | 14 +- 16 files changed, 830 insertions(+), 311 deletions(-) create mode 100644 arch/x86/kvm/vmx/main.c create mode 100644 arch/x86/kvm/vmx/tdx.c create mode 100644 arch/x86/kvm/vmx/tdx.h create mode 100644 arch/x86/kvm/vmx/x86_ops.h
Signature · 1 line
2.25.1
PATCH v4 1/8 KVM: VMX: Move out vmx_x86_ops to 'main.c' to wrap VMX and TDX
From: Sean Christopherson <[email protected]>
KVM accesses Virtual Machine Control Structure (VMCS) with VMX instructions to operate on VM. TDX defines its data structure and TDX SEAMCALL APIs for VMM to operate on Trust Domain (TD) instead.
Trust Domain Virtual Processor State (TDVPS) is the root control structure of a TD VCPU. It helps the TDX module control the operation of the VCPU, and holds the VCPU state while the VCPU is not running. TDVPS is opaque to software and DMA access, accessible only by using the TDX module interface functions (such as TDH.VP.RD, TDH.VP.WR ,..). TDVPS includes TD VMCS, and TD VMCS auxiliary structures, such as virtual APIC page, virtualization exception information, etc. TDVPS is composed of Trust Domain Virtual Processor Root (TDVPR) which is the root page of TDVPS and Trust Domain Virtual Processor eXtension (TDVPX) pages which extend TDVPR to help provide enough physical space for the logical TDVPS structure.
Also, we have a new structure, Trust Domain Control Structure (TDCS) is the main control structure of a guest TD, and encrypted (using the guest TD's ephemeral private key). At a high level, TDCS holds information for controlling TD operation as a whole, execution, EPTP, MSR bitmaps, etc. KVM needs to set it up. Note that MSR bitmaps are held as part of TDCS (unlike VMX) because they are meant to have the same value for all VCPUs of the same TD. TDCS is a multi-page logical structure composed of multiple Trust Domain Control Extension (TDCX) physical pages. Trust Domain Root (TDR) is the root control structure of a guest TD and is encrypted using the TDX global private key. It holds a minimal set of state variables that enable guest TD control even during times when the TD's private key is not known, or when the TD's key management state does not permit access to memory encrypted using the TD's private key.
The following shows the relationship between those structures.
TDR--> TDCS per-TD
| \--> TDCX
\
\--> TDVPS per-TD VCPU
\--> TDVPR and TDVPXThe existing global struct kvm_x86_ops already defines an interface which fits with TDX. But kvm_x86_ops is system-wide, not per-VM structure. To allow VMX to coexist with TDs, the kvm_x86_ops callbacks will have wrappers "if (tdx) tdx_op() else vmx_op()" to switch VMX or TDX at run time.
To split the runtime switch, the VMX implementation, and the TDX implementation, add main.c, and move out the vmx_x86_ops hooks in preparation for adding TDX, which can coexist with VMX, i.e. KVM can run both VMs and TDs. Use 'vt' for the naming scheme as a nod to VT-x and as a concatenation of VmxTdx.
The current code looks as follows.
In vmx.c
static vmx_op() { ... }
static struct kvm_x86_ops vmx_x86_ops = {
.op = vmx_op,initialization code
The eventually converted code will look like In vmx.c, keep the VMX operations.
vmx_op() { ... }
VMX initialization
In tdx.c, define the TDX operations.
tdx_op() { ... }
TDX initialization
In x86_ops.h, declare the VMX and TDX operations.
vmx_op();
tdx_op();
In main.c, define common wrappers for VMX and VMX.
static vt_ops() { if (tdx) tdx_ops() else vmx_ops() }
static struct kvm_x86_ops vt_x86_ops = {
.op = vt_op,initialization to call VMX and TDX initialization
Opportunistically, fix the name inconsistency from vmx_create_vcpu() and vmx_free_vcpu() to vmx_vcpu_create() and vxm_vcpu_free().
--- arch/x86/kvm/Makefile | 2 +- arch/x86/kvm/vmx/main.c | 154 ++++++++++++++++ arch/x86/kvm/vmx/vmx.c | 360 +++++++++++-------------------------- arch/x86/kvm/vmx/x86_ops.h | 126 +++++++++++++ 4 files changed, 385 insertions(+), 257 deletions(-) create mode 100644 arch/x86/kvm/vmx/main.c create mode 100644 arch/x86/kvm/vmx/x86_ops.h
arch/x86/kvm/Makefile +1 -1
@@ -22,7 +22,7 @@ kvm-$(CONFIG_X86_64) += mmu/tdp_iter.o mmu/tdp_mmu.o kvm-$(CONFIG_KVM_XEN) += xen.o kvm-intel-y += vmx/vmx.o vmx/vmenter.o vmx/pmu_intel.o vmx/vmcs12.o \ - vmx/evmcs.o vmx/nested.o vmx/posted_intr.o + vmx/evmcs.o vmx/nested.o vmx/posted_intr.o vmx/main.o kvm-intel-$(CONFIG_X86_SGX_KVM) += vmx/sgx.o kvm-amd-y += svm/svm.o svm/vmenter.o svm/pmu.o svm/nested.o svm/avic.o svm/sev.o
arch/x86/kvm/vmx/main.c new file +154 -0
154 lines not on this page · raw message
arch/x86/kvm/vmx/vmx.c +104 -256
905 lines not on this page · raw message
arch/x86/kvm/vmx/x86_ops.h new file +126 -0
126 lines not on this page · raw message
Signature · 1 line
2.25.1
PATCH v4 2/8 KVM: TDX: Detect CPU feature on kernel module initialization
In reply to [email protected]From: Isaku Yamahata <[email protected]>
TDX requires several initialization steps for KVM to create guest TDs. Detect CPU feature, enable VMX (TDX is based on VMX), detect TDX module availability, and initialize TDX module. This patch implements the first step to detect CPU feature. Because VMX isn't enabled yet by VMXON instruction on KVM kernel module initialization, defer further initialization step until VMX is enabled by hardware_enable callback.
Introduce a module parameter, enable_tdx, to explicitly enable TDX KVM support. It's off by default to keep same behavior for those who don't use TDX. Implement CPU feature detection at KVM kernel module initialization as hardware_setup callback to check if CPU feature is available and get some CPU parameters.
--- arch/x86/kvm/Makefile | 1 + arch/x86/kvm/vmx/main.c | 15 +++++++++- arch/x86/kvm/vmx/tdx.c | 61 ++++++++++++++++++++++++++++++++++++++ arch/x86/kvm/vmx/x86_ops.h | 6 ++++ 4 files changed, 82 insertions(+), 1 deletion(-) create mode 100644 arch/x86/kvm/vmx/tdx.c
arch/x86/kvm/Makefile +1 -0
@@ -24,6 +24,7 @@ kvm-$(CONFIG_KVM_XEN) += xen.o kvm-intel-y += vmx/vmx.o vmx/vmenter.o vmx/pmu_intel.o vmx/vmcs12.o \ vmx/evmcs.o vmx/nested.o vmx/posted_intr.o vmx/main.o kvm-intel-$(CONFIG_X86_SGX_KVM) += vmx/sgx.o +kvm-intel-$(CONFIG_INTEL_TDX_HOST) += vmx/tdx.o kvm-amd-y += svm/svm.o svm/vmenter.o svm/pmu.o svm/nested.o svm/avic.o svm/sev.o
arch/x86/kvm/vmx/main.c +14 -1
@@ -6,6 +6,19 @@#include "nested.h" #include "pmu.h" +static __init int vt_hardware_setup (void ) +{ +int ret; + + ret =vmx_hardware_setup (); +if (ret) +return ret; + +tdx_hardware_setup (&vt_x86_ops); + +return 0 ; +} +struct kvm_x86_ops vt_x86_ops__initdata = { .name ="kvm_intel" ,
@@ -147,7 +160,7 @@ struct kvm_x86_init_ops vt_init_ops __initdata = { .cpu_has_kvm_support = vmx_cpu_has_kvm_support, .disabled_by_bios = vmx_disabled_by_bios, .check_processor_compatibility = vmx_check_processor_compat, - .hardware_setup = vmx_hardware_setup, + .hardware_setup = vt_hardware_setup, .handle_intel_pt_intr = NULL, .runtime_ops = &vt_x86_ops,
arch/x86/kvm/vmx/tdx.c new file +61 -0
61 lines not on this page · raw message
arch/x86/kvm/vmx/x86_ops.h +6 -0
@@ -123,4 +123,10 @@ void vmx_cancel_hv_timer(struct kvm_vcpu *vcpu);#endif void vmx_setup_mce (struct kvm_vcpu *vcpu); +#ifdef CONFIG_INTEL_TDX_HOST +void __init tdx_hardware_setup (struct kvm_x86_ops *x86_ops); +#else +static inline void tdx_hardware_setup (struct kvm_x86_ops *x86_ops) {} +#endif +#endif /* __KVM_X86_VMX_X86_OPS_H */
Signature · 1 line
2.25.1
PATCH v4 3/8 KVM: Enable hardware before doing arch VM initialization
In reply to [email protected]From: Sean Christopherson <[email protected]>
Swap the order of hardware_enable_all() and kvm_arch_init_vm() to accommodate Intel's TDX, which needs VMX to be enabled during VM init in order to make SEAMCALLs.
This also provides consistent ordering between kvm_create_vm() and kvm_destroy_vm() with respect to calling kvm_arch_destroy_vm() and hardware_disable_all().
--- virt/kvm/kvm_main.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
virt/kvm/kvm_main.c +7 -7
@@ -1105,19 +1105,19 @@ static struct kvm *kvm_create_vm(unsigned long type)rcu_assign_pointer (kvm->buses[i],kzalloc (sizeof (struct kvm_io_bus ),GFP_KERNEL_ACCOUNT ));if (!kvm->buses[i]) - goto out_err_no_arch_destroy_vm; + goto out_err_no_disable; } kvm->max_halt_poll_ns = halt_poll_ns; - r =kvm_arch_init_vm (kvm, type); -if (r) - goto out_err_no_arch_destroy_vm; - r =hardware_enable_all ();if (r) goto out_err_no_disable; + r =kvm_arch_init_vm (kvm, type); +if (r) + goto out_err_no_arch_destroy_vm; +#ifdef CONFIG_HAVE_KVM_IRQFD INIT_HLIST_HEAD (&kvm->irq_ack_notifier_list);#endif
@@ -1145,10 +1145,10 @@ static struct kvm *kvm_create_vm(unsigned long type)mmu_notifier_unregister (&kvm->mmu_notifier, current->mm);#endif out_err_no_mmu_notifier: -hardware_disable_all (); -out_err_no_disable:kvm_arch_destroy_vm (kvm); out_err_no_arch_destroy_vm: +hardware_disable_all (); +out_err_no_disable:WARN_ON_ONCE (!refcount_dec_and_test (&kvm->users_count));for (i =0 ; i <KVM_NR_BUSES ; i++)kfree (kvm_get_bus (kvm, i));
Signature · 1 line
2.25.1
PATCH v4 4/8 KVM: x86: Refactor KVM VMX module init/exit functions
In reply to [email protected]From: Isaku Yamahata <[email protected]>
Currently, KVM VMX module initialization/exit functions are a single function each. Refactor KVM VMX module initialization functions into KVM common part and VMX part so that TDX specific part can be added cleanly. Opportunistically refactor module exit function as well.
The current module initialization flow is, 1.) calculate the sizes of VMX kvm structure and VMX vcpu structure, 2.) report those sizes to the KVM common layer and KVM common initialization, and 3.) VMX specific system-wide initialization.
Refactor the KVM VMX module initialization function into functions with a wrapper function to separate VMX logic in vmx.c from a file, main.c, common among VMX and TDX. We have a wrapper function,
"vt_init() {vmx_pre_kvm_init(); kvm_init(); vmx_init(); }" in main.c, and vmx_pre_kvm_init() and vmx_init() in vmx.c. vmx_pre_kvm_init() calculates the sizes of VMX kvm structure and KVM vcpu structure, kvm_init() does system-wide initialization of the KVM common layer, and vmx_init() does system-wide VMX initialization.
The KVM architecture common layer allocates struct kvm with reported size for architecture-specific code. The KVM VMX module defines its structure as struct vmx_kvm { struct kvm; VMX specific members;} and uses it as struct vmx kvm. Similar for vcpu structure. TDX KVM patches will define TDX specific kvm and vcpu structures, add tdx_pre_kvm_init() to report the sizes of them to the KVM common layer.
The current module exit function is also a single function, a combination of VMX specific logic and common KVM logic. Refactor it into VMX specific logic and KVM common logic. This is just refactoring to keep the VMX specific logic in vmx.c from main.c.
--- arch/x86/kvm/vmx/main.c | 33 +++++++++++++ arch/x86/kvm/vmx/vmx.c | 97 +++++++++++++++++++------------------- arch/x86/kvm/vmx/x86_ops.h | 5 +- 3 files changed, 86 insertions(+), 49 deletions(-)
arch/x86/kvm/vmx/main.c +33 -0
@@ -165,3 +165,36 @@ struct kvm_x86_init_ops vt_init_ops __initdata = { .runtime_ops = &vt_x86_ops, }; + +static int __init vt_init (void ) +{ +unsigned int vcpu_size =0 , vcpu_align =0 ; +int r; + +vmx_pre_kvm_init (&vcpu_size, &vcpu_align); + + r =kvm_init (&vt_init_ops, vcpu_size, vcpu_align,THIS_MODULE ); +if (r) + goto err_vmx_post_exit; + + r =vmx_init (); +if (r) + goto err_kvm_exit; + +return 0 ; + +err_kvm_exit: +kvm_exit (); +err_vmx_post_exit: +vmx_post_kvm_exit (); +return r; +} +module_init (vt_init); + +static void vt_exit (void ) +{ +vmx_exit (); +kvm_exit (); +vmx_post_kvm_exit (); +} +module_exit (vt_exit);
arch/x86/kvm/vmx/vmx.c +49 -48
121 lines not on this page · raw message
arch/x86/kvm/vmx/x86_ops.h +4 -1
@@ -8,7 +8,10 @@#include "x86.h" -extern struct kvm_x86_init_ops vt_init_ops__initdata ; +void __init vmx_pre_kvm_init (unsigned int *vcpu_size,unsigned int *vcpu_align); +int __init vmx_init (void ); +void vmx_exit (void ); +void vmx_post_kvm_exit (void );__init int vmx_cpu_has_kvm_support (void );__init int vmx_disabled_by_bios (void );
Signature · 1 line
2.25.1
PATCH v4 5/8 KVM: TDX: Add placeholders for TDX VM/vcpu structure
In reply to [email protected]From: Isaku Yamahata <[email protected]>
Add placeholders TDX VM/vcpu structure that overlays with VMX VM/vcpu structures. Initialize VM structure size and vcpu size/align so that x86 KVM common code knows those size irrespective of VMX or TDX. Those structures will be populated as guest creation logic develops.
Add helper functions to check if the VM is guest TD and add conversion functions between KVM VM/VCPU and TDX VM/VCPU.
--- arch/x86/kvm/vmx/main.c | 3 +++ arch/x86/kvm/vmx/tdx.c | 11 ++++++++++ arch/x86/kvm/vmx/tdx.h | 43 ++++++++++++++++++++++++++++++++++++++ arch/x86/kvm/vmx/x86_ops.h | 4 ++++ 4 files changed, 61 insertions(+) create mode 100644 arch/x86/kvm/vmx/tdx.h
arch/x86/kvm/vmx/main.c +3 -0
@@ -171,6 +171,9 @@ static int __init vt_init(void)unsigned int vcpu_size =0 , vcpu_align =0 ;int r; +/* tdx_pre_kvm_init must be called before vmx_pre_kvm_init(). */ +tdx_pre_kvm_init (&vcpu_size, &vcpu_align, &vt_x86_ops.vm_size); +vmx_pre_kvm_init (&vcpu_size, &vcpu_align); r =kvm_init (&vt_init_ops, vcpu_size, vcpu_align,THIS_MODULE );
arch/x86/kvm/vmx/tdx.c +11 -0
@@ -3,6 +3,7 @@#include "capabilities.h" #include "x86_ops.h" +#include "tdx.h" #undef pr_fmt#define pr_fmt (fmt) "tdx: " fmt
@@ -59,3 +60,13 @@ void __init tdx_hardware_setup(struct kvm_x86_ops *x86_ops)if (__tdx_hardware_setup (&vt_x86_ops)) enable_tdx = false; } + +void __init tdx_pre_kvm_init (unsigned int *vcpu_size, +unsigned int *vcpu_align,unsigned int *vm_size) +{ + *vcpu_size =sizeof (struct vcpu_tdx ); + *vcpu_align = __alignof__(struct vcpu_tdx ); + +if (sizeof (struct kvm_tdx ) > *vm_size) + *vm_size =sizeof (struct kvm_tdx ); +}
arch/x86/kvm/vmx/tdx.h new file +43 -0
43 lines not on this page · raw message
arch/x86/kvm/vmx/x86_ops.h +4 -0
@@ -127,8 +127,12 @@ void vmx_cancel_hv_timer(struct kvm_vcpu *vcpu);void vmx_setup_mce (struct kvm_vcpu *vcpu);#ifdef CONFIG_INTEL_TDX_HOST +void __init tdx_pre_kvm_init (unsigned int *vcpu_size, +unsigned int *vcpu_align,unsigned int *vm_size);void __init tdx_hardware_setup (struct kvm_x86_ops *x86_ops);#else +static inline void tdx_pre_kvm_init ( +unsigned int *vcpu_size,unsigned int *vcpu_align,unsigned int *vm_size) {}static inline void tdx_hardware_setup (struct kvm_x86_ops *x86_ops) {}#endif
Signature · 1 line
2.25.1
PATCH v4 6/8 KVM: TDX: Add a function to initialize TDX module
In reply to [email protected]From: Isaku Yamahata <[email protected]>
Memory used for TDX is encrypted with an encryption key. An encryption key is assigned to guest TD, and TDX memory is encrypted. VMM calculates Trust Domain Memory Range (TDMR), a range of memory pages that can hold TDX memory encrypted with an encryption key. VMM allocates memory regions for Physical Address Metadata Table (PAMT) which the TDX module uses to track page states. Used for TDX memory, assigned to which guest TD, etc. VMM gives PAMT regions to the TDX module and initializes it which is also encrypted.
TDX requires more initialization steps in addition to VMX. As a preparation step, check if the CPU feature is available and enable VMX because the TDX module API requires VMX to be enabled to be functional. The next step is basic platform initialization. Check if TDX module API is available, call system-wide initialization API (TDH.SYS.INIT), and call LP initialization API (TDH.SYS.LP.INIT). Lastly, get system-wide parameters (TDH.SYS.INFO), allocate PAMT for TDX module to track page states (TDH.SYS.CONFIG), configure encryption key (TDH.SYS.KEY.CONFIG), and initialize PAMT (TDH.SYS.TDMR.INIT).
A TDX host patch series implements those details and it provides APIs, seamrr_enabled() to check if CPU feature is available, init_tdx() to initialize the TDX module, tdx_get_tdsysinfo() to get TDX system parameters.
Add a wrapper function to initialize the TDX module and get system-wide parameters via those APIs. Because TDX requires VMX enabled, It will be called on-demand when the first guest TD is created via x86 KVM init_vm callback.
--- arch/x86/kvm/vmx/tdx.c | 141 +++++++++++++++++++++++++++++++++++++++++ arch/x86/kvm/vmx/tdx.h | 4 ++ 2 files changed, 145 insertions(+)
arch/x86/kvm/vmx/tdx.c +141 -0
@@ -18,12 +18,153 @@ bool seamrr_enabled(void);static inline bool seamrr_enabled (void ) {return false; }#endif +/* +* workaround to compile. +* TODO: once the TDX module initiation code in x86 host is merged, remove this. +*/ +#if __has_include(<asm/tdx_host.h>) +#include <asm/tdx_host.h> +#else +struct tdx_cpuid_config { +u32 leaf; +u32 sub_leaf; +u32 eax; +u32 ebx; +u32 ecx; +u32 edx; +} __packed; + +struct tdsysinfo_struct { +/* The TDX Module Info */ +u32 attributes; +u32 vendor_id; +u32 build_date; +u16 build_num; +u16 minor_version; +u16 major_version; +u8 reserved0[14 ]; + +/* Memory Info */ +u16 max_tdmrs; +u16 max_reserved_per_tdmr; +u16 pamt_entry_size; +u8 reserved1[10 ]; + +/* Control Struct Info */ +u16 tdcs_base_size; +u8 reserved2[2 ]; +u16 tdvps_base_size; +u8 tdvps_xfam_dependent_size; +u8 reserved3[9 ]; + +/* TD Capabilities */ +u64 attributes_fixed0; +u64 attributes_fixed1; +u64 xfam_fixed0; +u64 xfam_fixed1; +u8 reserved4[32 ]; +u32 num_cpuid_config; + +/* TD CPUIDs */ +union { +struct tdx_cpuid_config cpuid_configs[0 ]; +u8 reserved5[892 ]; + }; +} __packed__aligned(1024) ; + +static inline int init_tdx (void ) {return -ENODEV ; } +static inline const struct tdsysinfo_struct *tdx_get_sysinfo (void ) {return NULL ; } +#endif +static bool __read_mostly enable_tdx = true;module_param_named (tdx, enable_tdx, bool,0644 ); +#define TDX_MAX_NR_CPUID_CONFIGS \ + ((sizeof(struct tdsysinfo_struct) - \ + offsetof(struct tdsysinfo_struct, cpuid_configs)) \ + / sizeof(struct tdx_cpuid_config)) + +struct tdx_capabilities { +u8 tdcs_nr_pages; +u8 tdvpx_nr_pages; + +u64 attrs_fixed0; +u64 attrs_fixed1; +u64 xfam_fixed0; +u64 xfam_fixed1; + +u32 nr_cpuid_configs; +struct tdx_cpuid_config cpuid_configs[TDX_MAX_NR_CPUID_CONFIGS ]; +}; + +/* Capabilities of KVM + the TDX module. */ +struct tdx_capabilities tdx_caps; +static u64 hkid_mask__ro_after_init ;static u8 hkid_start_pos__ro_after_init ; +static int __tdx_module_setup (void ) +{ +const struct tdsysinfo_struct *tdsysinfo; +int ret =0 ; + +BUILD_BUG_ON (sizeof (*tdsysinfo) !=1024 ); +BUILD_BUG_ON (TDX_MAX_NR_CPUID_CONFIGS !=37 ); + + ret =init_tdx (); +if (ret) { +pr_info ("Failed to initialize TDX module.\n" ); +return ret; + } + + tdsysinfo =tdx_get_sysinfo (); +if (tdx_caps.nr_cpuid_configs >TDX_MAX_NR_CPUID_CONFIGS ) +return -EIO ; + + tdx_caps = (struct tdx_capabilities ) { + .tdcs_nr_pages = tdsysinfo->tdcs_base_size /PAGE_SIZE , +/* +* TDVPS = TDVPR(4K page) + TDVPX(multiple 4K pages). +* -1 for TDVPR. +*/ + .tdvpx_nr_pages = tdsysinfo->tdvps_base_size /PAGE_SIZE -1 , + .attrs_fixed0 = tdsysinfo->attributes_fixed0, + .attrs_fixed1 = tdsysinfo->attributes_fixed1, + .xfam_fixed0 = tdsysinfo->xfam_fixed0, + .xfam_fixed1 = tdsysinfo->xfam_fixed1, + .nr_cpuid_configs = tdsysinfo->num_cpuid_config, + }; +if (!memcpy (tdx_caps.cpuid_configs, tdsysinfo->cpuid_configs, + tdsysinfo->num_cpuid_config * +sizeof (struct tdx_cpuid_config ))) +return -EIO ; + +return 0 ; +} + +int tdx_module_setup (void ) +{ +static DEFINE_MUTEX (tdx_init_lock); +static bool __read_mostly tdx_module_initialized; +int ret =0 ; + +mutex_lock (&tdx_init_lock); + +if (!tdx_module_initialized) { +if (enable_tdx) { + ret =__tdx_module_setup (); +if (ret) + enable_tdx = false; +else + tdx_module_initialized = true; + }else + ret = -EOPNOTSUPP ; + } + +mutex_unlock (&tdx_init_lock); +return ret; +} +static int __init __tdx_hardware_setup (struct kvm_x86_ops *x86_ops) {u32 max_pa;
arch/x86/kvm/vmx/tdx.h +4 -0
@@ -3,6 +3,8 @@#define __KVM_X86_TDX_H#ifdef CONFIG_INTEL_TDX_HOST +int tdx_module_setup (void ); +struct kvm_tdx {struct kvm kvm; };
@@ -31,6 +33,8 @@ static inline struct vcpu_tdx *to_tdx(struct kvm_vcpu *vcpu) return container_of(vcpu, struct vcpu_tdx, vcpu); }#else +static inline int tdx_module_setup (void ) {return -ENODEV ; }; +struct kvm_tdx ;struct vcpu_tdx ;
Signature · 1 line
2.25.1
PATCH v4 7/8 KVM: x86: Introduce vm_type to differentiate default VMs from confidential VMs
In reply to [email protected]From: Sean Christopherson <[email protected]>
Unlike default VMs, confidential VMs (Intel TDX and AMD SEV-ES) don't allow some operations (e.g., memory read/write, register state access, etc).
Introduce vm_type to track the type of the VM to x86 KVM. Other arch KVMs already use vm_type, KVM_INIT_VM accepts vm_type, and x86 KVM callback vm_init accepts vm_type. So follow them. Further, a different policy can be made based on vm_type. Define KVM_X86_DEFAULT_VM for default VM as default and define KVM_X86_TDX_VM for Intel TDX VM. The wrapper function will be defined as "bool is_td(kvm) { return vm_type == VM_TYPE_TDX; }"
Add a capability KVM_CAP_VM_TYPES to effectively allow device model, e.g. qemu, to query what VM types are supported by KVM. This (introduce a new capability and add vm_type) is chosen to align with other arch KVMs that have VM types already. Other arch KVMs uses different name to query supported vm types and there is no common name for it, so new name was chosen.
--- Documentation/virt/kvm/api.rst | 15 +++++++++++++++ arch/x86/include/asm/kvm-x86-ops.h | 1 + arch/x86/include/asm/kvm_host.h | 2 ++ arch/x86/include/uapi/asm/kvm.h | 3 +++ arch/x86/kvm/svm/svm.c | 6 ++++++ arch/x86/kvm/vmx/main.c | 1 + arch/x86/kvm/vmx/vmx.c | 5 +++++ arch/x86/kvm/vmx/x86_ops.h | 1 + arch/x86/kvm/x86.c | 9 ++++++++- include/uapi/linux/kvm.h | 1 + tools/arch/x86/include/uapi/asm/kvm.h | 3 +++ tools/include/uapi/linux/kvm.h | 1 + 12 files changed, 47 insertions(+), 1 deletion(-)
Documentation/virt/kvm/api.rst +15 -0
@@ -147,15 +147,30 @@ described as 'basic' will be available. The new VM has no virtual cpus and no memory. You probably want to use 0 as machine type. +X86: +^^^^ + +Supported vm type can be queried from KVM_CAP_VM_TYPES, which returns the +bitmap of supported vm types. The 1-setting of bit @n means vm type with +value @n is supported. + +S390: +^^^^^ + In order to create user controlled virtual machines on S390, check KVM_CAP_S390_UCONTROL and use the flag KVM_VM_S390_UCONTROL as privileged user (CAP_SYS_ADMIN). +MIPS: +^^^^^ + To use hardware assisted virtualization on MIPS (VZ ASE) rather than the default trap & emulate implementation (which changes the virtual memory layout to fit in user mode), check KVM_CAP_MIPS_VZ and use the flag KVM_VM_MIPS_VZ. +ARM64: +^^^^^^ On arm64, the physical address size for a VM (IPA Size limit) is limited to 40bits by default. The limit can be configured if the host supports the
arch/x86/include/asm/kvm-x86-ops.h +1 -0
@@ -18,6 +18,7 @@ KVM_X86_OP_NULL(hardware_unsetup) KVM_X86_OP_NULL(cpu_has_accelerated_tpr) KVM_X86_OP(has_emulated_msr) KVM_X86_OP(vcpu_after_set_cpuid) +KVM_X86_OP(is_vm_type_supported) KVM_X86_OP(vm_init) KVM_X86_OP_NULL(vm_destroy) KVM_X86_OP(vcpu_create)
arch/x86/include/asm/kvm_host.h +2 -0
@@ -1048,6 +1048,7 @@ struct kvm_x86_msr_filter {#define APICV_INHIBIT_REASON_ABSENT 7struct kvm_arch { +unsigned long vm_type;unsigned long n_used_mmu_pages;unsigned long n_requested_mmu_pages;unsigned long n_max_mmu_pages;
@@ -1322,6 +1323,7 @@ struct kvm_x86_ops {bool (*has_emulated_msr)(struct kvm *kvm,u32 index);void (*vcpu_after_set_cpuid)(struct kvm_vcpu *vcpu); +bool (*is_vm_type_supported)(unsigned long vm_type);unsigned int vm_size;int (*vm_init)(struct kvm *kvm);void (*vm_destroy)(struct kvm *kvm);
arch/x86/include/uapi/asm/kvm.h +3 -0
@@ -525,4 +525,7 @@ struct kvm_pmu_event_filter {#define KVM_VCPU_TSC_CTRL 0/* control group for the timestamp counter (TSC) */ #define KVM_VCPU_TSC_OFFSET 0/* attribute for the TSC offset */ +#define KVM_X86_DEFAULT_VM 0 +#define KVM_X86_TDX_VM 1 +#endif /* _ASM_X86_KVM_H */
arch/x86/kvm/svm/svm.c +6 -0
@@ -4439,6 +4439,11 @@ static void svm_vm_destroy(struct kvm *kvm)sev_vm_destroy (kvm); } +static bool svm_is_vm_type_supported (unsigned long type) +{ +return type ==KVM_X86_DEFAULT_VM ; +} +static int svm_vm_init (struct kvm *kvm) {if (!pause_filter_count || !pause_filter_thresh)
@@ -4466,6 +4471,7 @@ static struct kvm_x86_ops svm_x86_ops __initdata = { .vcpu_free = svm_free_vcpu, .vcpu_reset = svm_vcpu_reset, + .is_vm_type_supported = svm_is_vm_type_supported, .vm_size = sizeof(struct kvm_svm), .vm_init = svm_vm_init, .vm_destroy = svm_vm_destroy,
arch/x86/kvm/vmx/main.c +1 -0
@@ -29,6 +29,7 @@ struct kvm_x86_ops vt_x86_ops __initdata = { .cpu_has_accelerated_tpr = report_flexpriority, .has_emulated_msr = vmx_has_emulated_msr, + .is_vm_type_supported = vmx_is_vm_type_supported, .vm_size = sizeof(struct kvm_vmx), .vm_init = vmx_vm_init,
arch/x86/kvm/vmx/vmx.c +5 -0
@@ -7079,6 +7079,11 @@ int vmx_vcpu_create(struct kvm_vcpu *vcpu)return err; } +bool vmx_is_vm_type_supported (unsigned long type) +{ +return type ==KVM_X86_DEFAULT_VM ; +} +#define L1TF_MSG_SMT "L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details.\n"#define L1TF_MSG_L1D "L1TF CPU bug present and virtualization mitigation disabled, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details.\n"
arch/x86/kvm/vmx/x86_ops.h +1 -0
@@ -25,6 +25,7 @@ void vmx_hardware_unsetup(void);int vmx_hardware_enable (void );void vmx_hardware_disable (void );bool report_flexpriority (void ); +bool vmx_is_vm_type_supported (unsigned long type);int vmx_vm_init (struct kvm *kvm);int vmx_vcpu_create (struct kvm_vcpu *vcpu);int vmx_vcpu_pre_run (struct kvm_vcpu *vcpu);
arch/x86/kvm/x86.c +8 -1
@@ -4331,6 +4331,11 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) r =sizeof (struct kvm_xsave );break ; } +case KVM_CAP_VM_TYPES : + r =BIT (KVM_X86_DEFAULT_VM ); +if (static_call (kvm_x86_is_vm_type_supported)(KVM_X86_TDX_VM )) + r |=BIT (KVM_X86_TDX_VM ); +break ;default :break ; }
@@ -11561,9 +11566,11 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)int ret;unsigned long flags; -if (type) +if (!static_call (kvm_x86_is_vm_type_supported)(type))return -EINVAL ; + kvm->arch.vm_type = type; + ret =kvm_page_track_init (kvm);if (ret)return ret;
include/uapi/linux/kvm.h +1 -0
@@ -1134,6 +1134,7 @@ struct kvm_ppc_resize_hpt {#define KVM_CAP_VM_GPA_BITS 207#define KVM_CAP_XSAVE2 208#define KVM_CAP_SYS_ATTRIBUTES 209 +#define KVM_CAP_VM_TYPES 210#ifdef KVM_CAP_IRQ_ROUTING
tools/arch/x86/include/uapi/asm/kvm.h +3 -0
@@ -525,4 +525,7 @@ struct kvm_pmu_event_filter {#define KVM_VCPU_TSC_CTRL 0/* control group for the timestamp counter (TSC) */ #define KVM_VCPU_TSC_OFFSET 0/* attribute for the TSC offset */ +#define KVM_X86_DEFAULT_VM 0 +#define KVM_X86_TDX_VM 1 +#endif /* _ASM_X86_KVM_H */
tools/include/uapi/linux/kvm.h +1 -0
@@ -1134,6 +1134,7 @@ struct kvm_ppc_resize_hpt {#define KVM_CAP_VM_GPA_BITS 207#define KVM_CAP_XSAVE2 208#define KVM_CAP_SYS_ATTRIBUTES 209 +#define KVM_CAP_VM_TYPES 210#ifdef KVM_CAP_IRQ_ROUTING
Signature · 1 line
2.25.1
PATCH v4 8/8 KVM: TDX: Make TDX VM type supported
In reply to [email protected]From: Isaku Yamahata <[email protected]>
As first step TDX VM support, return that TDX VM type supported to device model, e.g. qemu. The callback to create guest TD is vm_init callback for KVM_CREATE_VM. Add a place holder function and call a function to initialize TDX module on demand because in that callback VMX is enabled by hardware_enable callback (vmx_hardware_enable).
--- arch/x86/kvm/vmx/main.c | 24 ++++++++++++++++++++++-- arch/x86/kvm/vmx/tdx.c | 5 +++++ arch/x86/kvm/vmx/vmx.c | 5 ----- arch/x86/kvm/vmx/x86_ops.h | 3 ++- 4 files changed, 29 insertions(+), 8 deletions(-)
arch/x86/kvm/vmx/main.c +22 -2
@@ -5,6 +5,12 @@#include "vmx.h" #include "nested.h" #include "pmu.h" +#include "tdx.h" + +static bool vt_is_vm_type_supported (unsigned long type) +{ +return type ==KVM_X86_DEFAULT_VM ||tdx_is_vm_type_supported (type); +}static __init int vt_hardware_setup (void ) {
@@ -19,6 +25,20 @@ static __init int vt_hardware_setup(void)return 0 ; } +static int vt_vm_init (struct kvm *kvm) +{ +int ret; + +if (is_td (kvm)) { + ret =tdx_module_setup (); +if (ret) +return ret; +return -EOPNOTSUPP ;/* Not ready to create guest TD yet. */ + } + +return vmx_vm_init (kvm); +} +struct kvm_x86_ops vt_x86_ops__initdata = { .name ="kvm_intel" ,
@@ -29,9 +49,9 @@ struct kvm_x86_ops vt_x86_ops __initdata = { .cpu_has_accelerated_tpr = report_flexpriority, .has_emulated_msr = vmx_has_emulated_msr, - .is_vm_type_supported = vmx_is_vm_type_supported, + .is_vm_type_supported = vt_is_vm_type_supported, .vm_size = sizeof(struct kvm_vmx), - .vm_init = vmx_vm_init, + .vm_init = vt_vm_init, .vcpu_create = vmx_vcpu_create, .vcpu_free = vmx_vcpu_free,
arch/x86/kvm/vmx/tdx.c +5 -0
@@ -165,6 +165,11 @@ int tdx_module_setup(void)return ret; } +bool tdx_is_vm_type_supported (unsigned long type) +{ +return type ==KVM_X86_TDX_VM &&READ_ONCE (enable_tdx); +} +static int __init __tdx_hardware_setup (struct kvm_x86_ops *x86_ops) {u32 max_pa;
arch/x86/kvm/vmx/vmx.c +0 -5
@@ -7079,11 +7079,6 @@ int vmx_vcpu_create(struct kvm_vcpu *vcpu)return err; } -bool vmx_is_vm_type_supported (unsigned long type) -{ -return type ==KVM_X86_DEFAULT_VM ; -} -#define L1TF_MSG_SMT "L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details.\n"#define L1TF_MSG_L1D "L1TF CPU bug present and virtualization mitigation disabled, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details.\n"
arch/x86/kvm/vmx/x86_ops.h +2 -1
@@ -25,7 +25,6 @@ void vmx_hardware_unsetup(void);int vmx_hardware_enable (void );void vmx_hardware_disable (void );bool report_flexpriority (void ); -bool vmx_is_vm_type_supported (unsigned long type);int vmx_vm_init (struct kvm *kvm);int vmx_vcpu_create (struct kvm_vcpu *vcpu);int vmx_vcpu_pre_run (struct kvm_vcpu *vcpu);
@@ -130,10 +129,12 @@ void vmx_setup_mce(struct kvm_vcpu *vcpu);#ifdef CONFIG_INTEL_TDX_HOST void __init tdx_pre_kvm_init (unsigned int *vcpu_size,unsigned int *vcpu_align,unsigned int *vm_size); +bool tdx_is_vm_type_supported (unsigned long type);void __init tdx_hardware_setup (struct kvm_x86_ops *x86_ops);#else static inline void tdx_pre_kvm_init (unsigned int *vcpu_size,unsigned int *vcpu_align,unsigned int *vm_size) {} +static inline bool tdx_is_vm_type_supported (unsigned long type) {return false; }static inline void tdx_hardware_setup (struct kvm_x86_ops *x86_ops) {}#endif
Signature · 1 line
2.25.1