Re: [RFC PATCH v4 2/4] x86/sgx: Implement support for MADV_WILLNEED

jarkko
2023-02-17T21:50:12Z

On Tue, Feb 14, 2023 at 09:47:24AM +0000, Huang, Kai wrote:
> On Fri, 2023-01-27 at 20:55 -0800, Haitao Huang wrote:
> > @@ -97,10 +99,81 @@ static int sgx_mmap(struct file *file, struct vm_area_struct *vma)
> >   vma->vm_ops = &sgx_vm_ops;
> >   vma->vm_flags |= VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP | VM_IO;
> >   vma->vm_private_data = encl;
> > + vma->vm_pgoff = PFN_DOWN(vma->vm_start - encl->base);
> >
> >   return 0;
> >  }
>
> Perhaps I am missing something, but above change looks weird.
>
> Conceptually, it doesn't/shouldn't belong to this series, which essentially
> preallocates and does EAUG EPC pages for a (or part of) given enclave. The EAUG
> logic should already be working for the normal fault path, which means the code
> change above either: 1) has been done at other place; 2) isn't needed.
>
> I have kinda forgotten the userspace sequence to create an enclave. If I recall
> correctly, you do below to create an enclave:
>
> 1) encl_fd = open("/dev/sgx_enclave");
> 2) encl_addr = mmap(encl_fd, encl_size, 0 /* pgoff */);
> 3) IOCTL(ECREATE, encl_addr, encl_size);
>
> Would the above code change break the "mmap()" in above step 2?

Good catch! Actually shouldn't be validate it to be always zero? We
are essentially MAP_ANONYMOUS mapping semantics with a device file.

BR, Jarkko