sgx: update virt EPC device path and docs

The latest kvm-sgx code has renamed sgx_virt_epc device node to sgx_vepc. Update cloud-hypervisor code and documentation to follow this. Signed-off-by: Mikko Ylinen <[email protected]>
0x88888888 · Apr 30, 2021 · 3b18caf · 3b18caf
1 parent 7ca4d40
commit 3b18caf
Show file tree

Hide file tree

Showing 2 changed files with 5 additions and 5 deletions.
diff --git a/docs/intel_sgx.md b/docs/intel_sgx.md
@@ -19,7 +19,7 @@ following [instructions](https://github.com/intel/linux-sgx).
 
 ## Cloud-Hypervisor support
 
-Assuming the host exposes `/dev/sgx_virt_epc`, we can pass SGX enclaves through
+Assuming the host exposes `/dev/sgx_vepc`, we can pass SGX enclaves through
 the guest.
 
 In order to use SGX enclaves within a Cloud-Hypervisor VM, we must define one
@@ -43,13 +43,13 @@ have been correctly created under `/dev/sgx`:
 
 ```bash
 ls /dev/sgx*
-/dev/sgx_enclave  /dev/sgx_provision  /dev/sgx_virt_epc
+/dev/sgx_enclave  /dev/sgx_provision  /dev/sgx_vepc
 ```
 
 From this point, it is possible to run any SGX application from the guest, as
 it will access `/dev/sgx_enclave` device to create dedicated SGX enclaves.
 
 Note: There is only one contiguous SGX EPC region, which contains all SGX EPC
 sections. This region is exposed through ACPI and marked as reserved through
-the e820 table. It is treated yet as another device, which means it should
+the e820 table. It is treated as yet another device, which means it should
 appear at the end of the guest address space.
diff --git a/vmm/src/memory_manager.rs b/vmm/src/memory_manager.rs
@@ -1408,7 +1408,7 @@ impl MemoryManager {
             let file = OpenOptions::new()
                 .read(true)
                 .write(true)
-                .open("/dev/sgx_virt_epc")
+                .open("/dev/sgx_vepc")
                 .map_err(Error::SgxVirtEpcOpen)?;
 
             let prot = PROT_READ | PROT_WRITE;
@@ -1419,7 +1419,7 @@ impl MemoryManager {
 
             // We can't use the vm-memory crate to perform the memory mapping
             // here as it would try to ensure the size of the backing file is
-            // matching the size of the expected mapping. The /dev/sgx_virt_epc
+            // matching the size of the expected mapping. The /dev/sgx_vepc
             // device does not work that way, it provides a file descriptor
             // which is not matching the mapping size, as it's a just a way to
             // let KVM know that an EPC section is being created for the guest.