[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7183af76-655f-b147-13d0-0aa19750eabd@intel.com>
Date: Thu, 12 Aug 2021 13:04:00 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: linux-sgx@...r.kernel.org,
Reinette Chatre <reinette.chatre@...el.com>,
Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>, Jonathan Corbet <corbet@....net>,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH RFC v3] x86/sgx: Add /proc/sys/kernel/sgx/total_mem
On 8/12/21 12:53 PM, Jarkko Sakkinen wrote:
> On Wed, Aug 11, 2021 at 07:30:13AM -0700, Dave Hansen wrote:
>> On 8/10/21 8:21 PM, Jarkko Sakkinen wrote:
>>> +The following sysctl files can be found in the ``/proc/sys/kernel/sgx/`` directory:
>>> +
>>> +``total_mem``
>>> + The total amount of SGX protected memory in bytes available in the system
>>> + available for use. In other words, it describes the size of the Enclave
>>> + Page Cache (EPC).
>>
>> I've been acting as if /proc is deprecated for new stuff. Shouldn't
>> this be going in sysfs?
>
> Are sysctl variables deprecated too?
Adding new ones is. Adding new, related functionality to existing ones
is OK. Anything not related to processes shouldn't added /proc, for
many years now.
>> I figured, at some point, someone is going to ask for NUMA statistics.
>> That would tend to point in the direction of us needing something in:
>>
>> /sys/devices/system/node/nodeN/
>>
>> Maybe 'sgxinfo' or 'sgxstat' to go along with 'meminfo'.
>
> Is conetents of meminfo freezed or can a new line added, e.g.
>
> Node 0 SgxMemTotal: 32825700 kB
New lines get added occasionally. Things like AnonHugePages and
KReclaimable are _relatively_ new additions.
> If a new file is needed, I would name it as "sgxmeminfo"
Yeah, that would fine. The other option would be to have an
"archmeminfo" which other architectures might end up being able to use.
That has the advantage of getting picked up by common tooling more widely.
We might also be able to use it for things on x86 like TDX metadata to
enumerate how much memory is being consumed.
>> But, we'll probably also end up needing some stats for other things.
>> Folks have, for instance, asked for a counter of the number of
>> instantiated enclaves.
>>
>> We could also use the drivers' namespaces:
>>
>> /sys/class/misc/sgx_enclave
>> /sys/class/misc/sgx_provision
>> /sys/class/misc/sgx_vepc
>>
>> although that is a bit awkward for reporting global resources like memory.
>
> I think these stats should be available when the driver is not enabled.
Do you mean like if it were compiled out? Or if we booted up and
decided to disallow /dev/sgx_enclave because of Launch Control being locked?
Either way, the drivers seem to be an odd place to do this. Probably a
last resort if we don't find a better home.
Powered by blists - more mailing lists