External/cloud-hypervisor
1
0
Fork 0
mirror of https://github.com/cloud-hypervisor/cloud-hypervisor.git synced 2025-02-02 01:45:21 +00:00
Code Issues Packages Projects Releases Wiki Activity

sgx: update virt EPC device path and docs

Browse Source 
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 <mikko.ylinen@intel.com>
This commit is contained in:
Mikko Ylinen 2021-04-29 14:52:16 +03:00 committed by Sebastien Boeuf
parent 7ca4d40d49
commit 3b18caf229
2 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/intel_sgx.md
View File

@ -19,7 +19,7 @@ following [instructions](https://github.com/intel/linux-sgx).
## Cloud-Hypervisor support ## 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. the guest.
In order to use SGX enclaves within a Cloud-Hypervisor VM, we must define one In order to use SGX enclaves within a Cloud-Hypervisor VM, we must define one
@ -43,7 +43,7 @@ have been correctly created under `/dev/sgx`:
```bash ```bash
ls /dev/sgx* 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 From this point, it is possible to run any SGX application from the guest, as
@ -51,5 +51,5 @@ 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 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 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. appear at the end of the guest address space.

4
vmm/src/memory_manager.rs
View File

@ -1408,7 +1408,7 @@ impl MemoryManager {
let file = OpenOptions::new() let file = OpenOptions::new()
.read(true) .read(true)
.write(true) .write(true)
.open("/dev/sgx_virt_epc") .open("/dev/sgx_vepc")
.map_err(Error::SgxVirtEpcOpen)?; .map_err(Error::SgxVirtEpcOpen)?;
let prot = PROT_READ | PROT_WRITE; 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 // 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 // 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 // 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 // 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. // let KVM know that an EPC section is being created for the guest.