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

["jarkko@kernel.org" <jarkko@kernel.org>]

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