All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Fernandez <martin.fernandez@eclypsium.com>
To: linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	x86@kernel.org, hpa@zytor.com, dave.hansen@linux.intel.com,
	luto@kernel.org, peterz@infradead.org, ardb@kernel.org,
	dvhart@infradead.org, andy@infradead.org,
	gregkh@linuxfoundation.org, rafael@kernel.org,
	martin.fernandez@eclypsium.com, daniel.gutson@eclypsium.com,
	hughsient@gmail.com
Subject: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs
Date: Wed, 27 Oct 2021 16:55:06 -0300	[thread overview]
Message-ID: <20211027195511.207552-1-martin.fernandez@eclypsium.com> (raw)

Show for each NUMA node the value of EFI_MEMORY_CPU_CRYPTO in its
memory.

This is a serie of patches for exporting the needed information to
userspace to determine if a machine is using Intel's TME or MKTME.

In a next patch I'm going to export if TME/MKTME is activated by the
BIOS to sysfs, since right now for the user, this information is only
available in the kernel logs, and it's not appropriate for fwupd to
scan the boot logs just to parse an integer. I'm looking for
suggestions for where to store this value.

Changelog v2:

The value shown in each node now only corresponds to memory in that
node in particular

Martin Fernandez (5):
  Extend memblock to support memory encryption
  Extend pg_data_t to hold information about memory encryption
  Extend e820_table to hold information about memory encryption
  Mark e820_entries as crypto capable from EFI memmap
  Show in sysfs if a memory node is able to do memory encryption

 Documentation/ABI/testing/sysfs-devices-node |  12 +++
 arch/x86/include/asm/e820/api.h              |   2 +
 arch/x86/include/asm/e820/types.h            |   1 +
 arch/x86/include/asm/numa.h                  |   7 ++
 arch/x86/kernel/e820.c                       |  32 +++++-
 arch/x86/mm/numa.c                           |   5 +
 arch/x86/mm/numa_emulation.c                 |   2 +-
 arch/x86/platform/efi/efi.c                  | 108 +++++++++++++++++++
 drivers/base/node.c                          |  72 ++++++++++++-
 include/linux/memblock.h                     |   6 ++
 include/linux/mmzone.h                       |   2 +
 include/linux/node.h                         |   1 +
 mm/memblock.c                                |  74 +++++++++++++
 mm/page_alloc.c                              |   1 +
 14 files changed, 321 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-node


base-commit: 3906fe9bb7f1a2c8667ae54e967dc8690824f4ea
--
2.30.2


             reply	other threads:[~2021-10-27 19:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-27 19:55 Martin Fernandez [this message]
2021-10-27 19:55 ` [PATCH v2 1/5] Extend memblock to support memory encryption Martin Fernandez
2021-10-27 19:55 ` [PATCH v2 2/5] Extend pg_data_t to hold information about " Martin Fernandez
2021-10-27 19:55 ` [PATCH v2 3/5] Extend e820_table " Martin Fernandez
2021-10-27 19:55 ` [PATCH v2 4/5] Mark e820_entries as crypto capable from EFI memmap Martin Fernandez
2021-10-27 19:55 ` [PATCH v2 5/5] Show in sysfs if a memory node is able to do memory encryption Martin Fernandez
2021-10-28 18:09   ` Dave Hansen
2021-10-27 20:21 ` [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs Dave Hansen
2021-10-28 14:28   ` Martin Fernandez
2021-10-28 14:55     ` Borislav Petkov
2021-10-28 16:03       ` Richard Hughes
2021-10-28 16:35         ` Borislav Petkov
2021-10-28 17:39           ` Martin Fernandez
2021-10-28 18:10             ` Borislav Petkov
2021-10-28 18:17               ` Dave Hansen
2021-10-29 17:08             ` Dave Hansen
2021-11-01 18:12               ` Martin Fernandez
2021-11-01 20:10               ` Martin Fernandez
2021-10-29 13:14           ` Richard Hughes
2021-10-28 15:24     ` Dave Hansen

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=20211027195511.207552-1-martin.fernandez@eclypsium.com \
    --to=martin.fernandez@eclypsium.com \
    --cc=andy@infradead.org \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=daniel.gutson@eclypsium.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvhart@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=hughsient@gmail.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@kernel.org \
    --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.