SME is typically enabled by BIOS or other firmware at boot time. This is done by setting the appropriate {{x86|MSR}} bit to 1. Once activate, software can simply set the encryption C-bit (enCrypted) on the desired [[page]]. It's worth noting that the location of the C-bit is actually implementation-specific and must determined by making the appropriate {{x86|CPUID}} call. Pages with a C-bit set to 1 go through the encryption engine and are stored encrypted in memory. Likewise, pages with a C-bit set to 0 go directly to memory. This means unencrypted pages do not incur any added latency because of this feature. It's worth noting that encryption I/O pages are not allowed and must have a C-bit of 0.

SME is typically enabled by BIOS or other firmware at boot time. This is done by setting the appropriate {{x86|MSR}} bit to 1. Once activate, software can simply set the encryption C-bit (enCrypted) on the desired [[page]]. It's worth noting that the location of the C-bit is actually implementation-specific and must determined by making the appropriate {{x86|CPUID}} call. Pages with a C-bit set to 1 go through the encryption engine and are stored encrypted in memory. Likewise, pages with a C-bit set to 0 go directly to memory. This means unencrypted pages do not incur any added latency because of this feature. It's worth noting that encryption I/O pages are not allowed and must have a C-bit of 0.

If SEV is supported and enabled, on each SEV-enabled VM, SME mode is enabled with that VM-specified encryption key. Under SEV, the {{x86|ASID}} field in the [[page table]] is used as the key index that identifies which encryption key is used to encrypt and decrypt the memory traffic associated with that VM. SEV-enabled VMs can control their own C-bit for memory pages they want encrypted. This allows those VMs to determine which pages are private (C-bit = 1) or shared (C-bit = 0). The location of that C-bit is the same location as defined under SME. It's worth noting that this control is limited to data page. In other words, memory accesses such as guest [[page tables]] and [[instruction fetches]] are always private, regardless of the value of the C-bit (i.e., in those cases the C-bit is a [[don't care]]). This was done in order to ensure that non-guest entities such as the hypervisor itself cannot inject their own code into the SEV-enabled guest VM. If the C-bit is an address bit, this bit is masked from the guest physical address when it is translated through the nested page tables. The hypervisor itself does not need to be aware of which pages the guest VM marked as private. For example, a guest accessing a particular virtual address will get translated to a specific physical address with the C-bit set to 1 indicating the page should be encrypted. A specific virtual address is then used for the translation and the C-bit value from the guest physical address is saved and used on the final physical address after the nested table translation took place.

If SEV is supported and enabled, on each SEV-enabled VM, SME mode is enabled with that VM-specified encryption key. Under SEV, the {{x86|ASID}} field in the [[page table]] is used as the key index that identifies which encryption key is used to encrypt and decrypt the memory traffic associated with that VM. SEV-enabled VMs can control their own C-bit for memory pages they want encrypted. This allows those VMs to determine which pages are private (C-bit = 1) or shared (C-bit = 0). The location of that C-bit is the same location as defined under SME. It's worth noting that this control is limited to data page. In other words, memory accesses such as guest [[page tables]] and [[instruction fetches]] are always private, regardless of the value of the C-bit (i.e., in those cases the C-bit is a [[don't care]]). This was done in order to ensure that non-guest entities such as the hypervisor itself cannot inject their own code into the SEV-enabled guest VM. If the C-bit is an address bit, this bit is masked from the guest physical address when it is translated through the nested page tables. The hypervisor itself does not need to be aware of which pages the guest VM marked as private. For example, a guest accessing a particular virtual address will get translated to a specific physical address with the C-bit set to 1 indicating the page should be encrypted. A specific virtual address is then used for the translation and the C-bit value from the guest physical address is saved and used on the final physical address after the nested table translation took place.