Lines Matching +full:boot +full:- +full:pages
1 .. SPDX-License-Identifier: GPL-2.0
5 Hyper-V can create and run Linux guests that are Confidential Computing
9 CoCo VMs on Hyper-V share the generic CoCo VM threat model and security
10 objectives described in Documentation/security/snp-tdx-threat-model.rst. Note
11 that Hyper-V specific code in Linux refers to CoCo VMs as "isolated VMs" or
14 A Linux CoCo VM on Hyper-V requires the cooperation and interaction of the
19 * The hardware runs a version of Windows/Hyper-V with support for CoCo VMs
25 * AMD processor with SEV-SNP. Hyper-V does not run guest VMs with AMD SME,
26 SEV, or SEV-ES encryption, and such encryption is not sufficient for a CoCo
27 VM on Hyper-V.
31 To create a CoCo VM, the "Isolated VM" attribute must be specified to Hyper-V
36 -----------------
37 Hyper-V CoCo VMs can run in two modes. The mode is selected when the VM is
40 * Fully-enlightened mode. In this mode, the guest operating system is
46 fully-enlightened case.
48 Conceptually, fully-enlightened mode and paravisor mode may be treated as
50 as a CoCo VM. Fully-enlightened mode is one end of the spectrum. A full
54 can run successfully. However, the Hyper-V implementation of paravisor mode
56 aspects of CoCo VMs are handled by the Hyper-V paravisor while the guest OS
61 the paravisor provides is hard-coded in the guest OS.
65 However, the Hyper-V paravisor generally handles more aspects of CoCo VMs
69 .. _Coconut project: https://github.com/coconut-svsm/svsm
76 The hardware architectural approach to fully-enlightened vs. paravisor mode
79 * With AMD SEV-SNP processors, in fully-enlightened mode the guest OS runs in
85 as defined by the SEV-SNP architecture. This mode simplifies guest management
88 * With Intel TDX processor, in fully-enlightened mode the guest OS runs in an
92 Hyper-V exposes a synthetic MSR to guests that describes the CoCo mode. This
93 MSR indicates if the underlying processor uses AMD SEV-SNP or Intel TDX, and
95 kernel image that can boot and run properly on either architecture, and in
99 -----------------
107 perform the early boot memory setup steps that are particularly tricky with
108 AMD SEV-SNP in fully-enlightened mode.
110 * #VC/#VE exception handling. In paravisor mode, Hyper-V configures the guest
116 * CPUID flags. Both AMD SEV-SNP and Intel TDX provide a CPUID flag in the
118 support. While these CPUID flags are visible in fully-enlightened CoCo VMs,
122 abstracting the differences between SEV-SNP and TDX. But the
123 cc_platform_has() abstraction also allows the Hyper-V paravisor configuration
125 flags are not set. The exception is early boot memory setup on SEV-SNP, which
126 tests the CPUID SEV-SNP flag. But not having the flag in Hyper-V paravisor
127 mode VM achieves the desired effect or not running SEV-SNP specific early
128 boot memory setup.
130 * Device emulation. In paravisor mode, the Hyper-V paravisor provides
131 emulation of devices such as the IO-APIC and TPM. Because the emulation
134 of the decrypted references that would be used in a fully-enlightened CoCo
142 __set_memory_enc_pgtable(). In fully-enlightened mode, the normal SEV-SNP and
143 TDX implementations of these callbacks are used. In paravisor mode, a Hyper-V
152 by CoCo-capable processors. In paravisor mode, the paravisor mediates
155 management features provided by the CoCo-capable physical processor, thereby
158 Hyper-V Hypercalls
159 ------------------
160 When in fully-enlightened mode, hypercalls made by the Linux guest are routed
161 directly to the hypervisor, just as in a non-CoCo VM. But in paravisor mode,
168 Guest communication with Hyper-V
169 --------------------------------
171 CoCo VMs, Hyper-V has VMBus and VMBus devices that communicate using memory
177 These Hyper-V and VMBus memory pages are marked as decrypted:
179 * VMBus monitor pages
181 * Synthetic interrupt controller (synic) related pages (unless supplied by
184 * Per-cpu hypercall input and output pages (unless running with a paravisor)
206 validate messages received over VMBus, instead of assuming that Hyper-V is
212 Two VMBus devices depend on the Hyper-V host to do DMA data transfers:
227 by the Linux PCI subsystem. On Hyper-V, these functions directly access MMIO
228 space, and the access traps to Hyper-V for emulation. But in CoCo VMs, memory
229 encryption prevents Hyper-V from reading the guest instruction stream to
236 ------------------------
241 the Hyper-V host. The memory is in an inconsistent state until all steps are
248 handler to fixup this case. But a CoCo VM running on Hyper-V may be
254 To avoid this problem, the Hyper-V specific functions for notifying the
255 hypervisor of the transition mark pages as "not present" while a transition
257 normal page fault is generated instead of #VC or #VE, and the page-fault-
259 encrypted/decrypted transition is complete, the pages are marked as "present"