> On 2/13/21 5:28 AM, Kai Huang wrote: > > SGX driver uses misc device /dev/sgx_enclave to support userspace to > > create enclave. Each file descriptor from opening /dev/sgx_enclave > > represents an enclave. > > Is this strictly true? Does dup(2) create a new enclave? I don't think dup() will create a new enclave. Enclave data structure is kept in filep->private_data, and only 'open' will create a new one. > > > Unlike SGX driver, KVM doesn't control how guest uses EPC, therefore > > EPC allocated to KVM guest is not associated to an encalve, and > > /dev/sgx_enclave is not suitable for allocating EPC for KVM > > ^ enclave Ops. Thanks. > > > guest. > > > > Having separate device nodes for SGX driver and KVM virtual EPC also > > allows separate permission control for running host SGX enclaves and > > KVM SGX guests. > > Specifically, 'sgx_vepc' is a less restrictive interface. It would make a lot of > sense to more tightly control access compared to 'sgx_enclave'. Sean mentioned the opposite is also likely, and I agree. Please see my reply to Sean's. > > > More specifically, to allocate a virtual EPC instance with particular > > size, the userspace hypervisor opens /dev/sgx_vepc, and uses mmap() > > with the intended size to get an address range of virtual EPC. Then > > it may use the address range to create one KVM memory slot as virtual > > EPC for guest. > > This paragraph doesn't really explain anything important to me. Both devices > require using mmap(). This paragraph was requested by Jarkko to explain how to use this /dev/sgx_vepc. Perhaps I can remove it? Or perhaps I can refine to "To use /dev/sgx_vepc to allocate a virtual EPC instance with particular size, the userspace hypervisor..."? > > With typos in the changelog fixed, I'm OK with the rest: > > Acked-by: Dave Hansen <dave.hansen@xxxxxxxxx> > > BTW... A lot of this patch is just a skeletal device driver. I'm a horrible device > driver writer, so take this ack as "everything seems explained well" versus "I > promise this will pass muster with the guys who review device drivers all day > long." Thanks.
