On Tue, 2021-02-09 at 13:36 -0800, Dave Hansen wrote:
> On 2/9/21 1:19 PM, Jarkko Sakkinen wrote:
> > > Without that clearly documented, it would be unwise to merge this.
> > E.g.
> >
> > - Have ioctl() to turn opened fd as vEPC.
> > - If FLC is disabled, you could only use the fd for creating vEPC.
> >
> > Quite easy stuff to implement.
>
> The most important question to me is not how close vEPC is today, but
> how close it will be in the future. It's basically the age old question
> of: do we make one syscall that does two things or two syscalls?
>
> Is there a _compelling_ reason to change direction? How much code would
> we save?
Basically we need to defer 'sgx_encl' related code from open to after mmap(). For
instance, We need to defer 'sgx_encl' allocation from open to SGX_IOC_ENCLAVE_CREATE.
And due to this change, we also need to move some members out of 'sgx_encl', and use
them as common for enclave and vEPC. The 'struct xarray page_array' would be a good
example.
The code we can save, from my first glance, is just misc_register("/dev/sgx_vepc")
related, maybe plus some mmap() related code. The logic to handle both host enclave
and vEPC still needs to be there.
To me the major concern is /dev/sgx_enclave, by its name, implies it is associated
with host enclave. Adding IOCTL to *convert* it to vEPC is just mixing things up, and
is ugly. If we really want to do this, IMHO we need at least change /dev/sgx_enclave
to /dev/sgx_epc, for instance, to imply the fd we opened and mmap()'d just represents
some raw EPC. However this is changing to existing userspace ABI.
Sean,
What's your opinion? Did I miss anything?
