All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Jarkko Sakkinen <jarkko@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>
Cc: reinette.chatre@intel.com, linux-kernel@vger.kernel.org,
	linux-sgx@vger.kernel.org
Subject: Re: [PATCH v13 2/2] x86/sgx: Add an attribute for the amount of SGX memory in a NUMA node
Date: Tue, 7 Dec 2021 11:36:50 -0800	[thread overview]
Message-ID: <f25d95e6-e129-597b-5d93-d7264feae8b8@intel.com> (raw)
In-Reply-To: <20211116162116.93081-2-jarkko@kernel.org>

On 11/16/21 8:21 AM, Jarkko Sakkinen 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.
> 
> Introduce CONFIG_HAVE_ARCH_NODE_DEV_GROUP opt-in flag to expose an arch
> specific attribute group, and add an attribute for the amount of SGX
> memory in bytes to each NUMA node:
> 
> /sys/devices/system/node/nodeX/x86/sgx_total_bytes

There's some context missing here:

This serves the same function for SGX memory as /proc/meminfo or
/sys/devices/system/node/nodeX/meminfo does for normal RAM.  It
enumerates how much physical SGX memory is present so that you can size
enclaves on different systems.

This specific file (sgx_total_bytes) is needed today to help drive the
SGX selftests.  The SGX selftests need to create overcommitted enclaves
which are larger than the physical SGX memory on the system.  They
currently use a CPUID-based approach which can diverge from the actual
amount of SGX memory available.  This file ensures that the selftests
can work efficiently and do not attempt stupid things like creating a
100,000 MB enclave on a system with 128 MB  of SGX memory.

The nodeX/x86 directory is used because SGX is highly x86-specific.
It's very unlikely that any other architecture (or even non-Intel x86
vendor) will ever implement SGX.  It needs its own directory (as opposed
to being in the nodeX/ "root") because this is expected to be the first
of a few different things that need to get exported.  This avoids
cluttering the root with several "sgx_*" files.

How many of these files will there be?  Just scanning /proc/meminfo,
these are the no-brainers that we have for RAM, but we need for SGX:

MemTotal:       xxxx kB // sgx_total_bytes (this patch)
MemFree:        yyyy kB // sgx_free_bytes
SwapTotal:      zzzz kB // sgx_swapped_bytes

So, at *least* three.  I think we will eventually end up needing
something more along the lines of a dozen.

  parent reply	other threads:[~2021-12-07 19:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-16 16:21 [PATCH v13 1/2] x86/sgx: Rename fallback labels in sgx_init() Jarkko Sakkinen
2021-11-16 16:21 ` [PATCH v13 2/2] x86/sgx: Add an attribute for the amount of SGX memory in a NUMA node Jarkko Sakkinen
2021-12-04 23:51   ` Jarkko Sakkinen
2021-12-07 19:36   ` Dave Hansen [this message]
2021-12-08 10:10     ` Borislav Petkov
2021-12-08 19:38       ` Dave Hansen
2021-12-09 12:08         ` Borislav Petkov
2021-12-11 15:37         ` Jarkko Sakkinen
2021-12-11 15:36     ` Jarkko Sakkinen
2021-12-09 15:35   ` [tip: x86/sgx] " tip-bot2 for Jarkko Sakkinen
2021-12-17 19:12   ` [PATCH v13 2/2] " Nathan Chancellor
2021-12-17 21:17     ` Dave Hansen
2021-12-17 22:04       ` Nathan Chancellor
2021-12-28 23:45     ` Jarkko Sakkinen
2022-01-02  4:54       ` Dave Hansen
2022-01-02 23:20         ` Nathan Chancellor
2022-01-04 16:52         ` Dave Hansen
2022-01-06 19:18         ` Jarkko Sakkinen
2022-01-07 11:42           ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f25d95e6-e129-597b-5d93-d7264feae8b8@intel.com \
    --to=dave.hansen@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=jarkko@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rafael@kernel.org \
    --cc=reinette.chatre@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.