On Thu, Apr 08, 2021 at 11:52:40AM +0300, Jarkko Sakkinen wrote:
> On Wed, Apr 07, 2021 at 06:15:33PM +0200, Borislav Petkov wrote:
> > On Wed, Apr 07, 2021 at 07:09:11PM +0300, Jarkko Sakkinen wrote:
> > > I left out "epc" because they are already prefixed with "sgx_".
> >
> > Are there any other "page" types which are going to be figurating in
> > some pseudofs or is "sgx" == "epc" in this case?
> >
> > > debugfs was my first shot, but for sure these could be sysfs.
> >
> > Ok, let's keep it in debugfs for now, it can always be made an ABI later
> > and moved to sysfs. But pls document what those are and what they do and
> > that when in debugfs, there are no guarantees that these interfaces will
> > be there in the future.
>
> I think these attributes are quite useful information to have available so
> I'd go actually doing sysfs attributes and create
> Documentation/ABI/stable/sysfs-driver-sgx to document them.
>
> Given that they would go then to the sysfs directory of the driver, then
> probably the legit names for the attributes ought to be:
>
> - nr_all_epc_pages
> - nr_free_epc_pages
>
> What do you think?
Actually I think read-only sysctl attributes would be a better idea.
The rationale for this is that we have two misc devices sgx_enclave and
sgx_provision, and these are global attributes even applicable to KVM.
It does not matter functionality-wise, but API-wise it'd look stupid to
directly associate to sgx_enclave.
I.e. I'd add something along the lines of
static struct ctl_path x86_sysctl_path[] = {
{ .procname = "kernel", },
{ .procname = "x86", },
{ }
};
static struct ctl_table x86_sysctl_table[] = {
{
.procname = "sgx_nr_all_pages",
.mode = 0444,
/* rest ... */
},
{
.procname = "sgx_nr_free_pages",
.mode = 0444,
/* rest ... */
},
{ }
};
And write Documentation/x86/proc.rst.
/Jarkko
