[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <eb41bbbe-8563-7b6d-3883-61ab43b0b10f@intel.com>
Date: Fri, 29 Oct 2021 11:06:52 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Reinette Chatre <reinette.chatre@...el.com>, jarkko@...nel.org,
linux-sgx@...r.kernel.org, shuah@...nel.org,
dave.hansen@...ux.intel.com
Cc: seanjc@...gle.com, linux-kselftest@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 03/15] x86/sgx: Add an attribute for the amount of SGX
memory in a NUMA node
On 10/28/21 1:37 PM, Reinette Chatre wrote:
> The amount of SGX memory on the system is determined by the BIOS and it
> varies wildly between systems. It can be from dozens of MB's on desktops
> or VM's, up to many GB's on servers. Just like for regular memory, it is
> sometimes useful to know the amount of usable SGX memory in the system.
>
> Add an attribute for the amount of SGX memory in bytes to each NUMA
> node. The path is /sys/devices/system/node/node[0-9]*/sgx/size.
> Calculate these values by summing up EPC section sizes for each node
> during the driver initalization.
For now, can we just make the selftests read the SGX CPUID section
leaves? It's not as precise as knowing how much the kernel actually
decided to use, but it's good enough for a selftest. It also means we
can merge something without having to worry about long-term ABI.
This is also why I once suggested that we first make the selftests
depend on some debugfs file that would be short-lived. But, if we use
CPUID, we don't even need to mess with debugfs.
You can even just steal the code from sgx_page_cache_init() to do it.
Would that work, or am I missing something?
Powered by blists - more mailing lists