On Mon, Dec 17, 2018 at 08:59:54PM -0800, Andy Lutomirski wrote:
> On Mon, Dec 17, 2018 at 2:20 PM Sean Christopherson
> <sean.j.christopherson@xxxxxxxxx> wrote:
> >
>
> > My brain is still sorting out the details, but I generally like the idea
> > of allocating an anon inode when creating an enclave, and exposing the
> > other ioctls() via the returned fd. This is essentially the approach
> > used by KVM to manage multiple "layers" of ioctls across KVM itself, VMs
> > and vCPUS. There are even similarities to accessing physical memory via
> > multiple disparate domains, e.g. host kernel, host userspace and guest.
> >
>
> In my mind, opening /dev/sgx would give you the requisite inode. I'm
> not 100% sure that the chardev infrastructure allows this, but I think
> it does.
Yes, this is what I was thinking too i.e.
enclave_fd = open("/dev/sgx/", O_RDWR);
After this enclave_fd "is" the enclave up until the file is closed.
> > The only potential hiccup I can see is the build flow. Currently,
> > EADD+EEXTEND is done via a work queue to avoid major performance issues
> > (10x regression) when userspace is building multiple enclaves in parallel
> > using goroutines to wrap Cgo (the issue might apply to any M:N scheduler,
> > but I've only confirmed the Golang case). The issue is that allocating
> > an EPC page acts like a blocking syscall when the EPC is under pressure,
> > i.e. an EPC page isn't immediately available. This causes Go's scheduler
> > to thrash and tank performance[1].
>
> What's the issue, and how does a workqueue help? I'm wondering if a
> nicer solution would be an ioctl to add lots of pages in a single
> call.
I don't think this really is an issue as long as the thread does not
depend on any VMAs.
/Jarkko
