From: Mike Rapoport <rppt@kernel.org>
To: Martin Fernandez <martin.fernandez@eclypsium.com>
Cc: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
platform-driver-x86@vger.kernel.org, linux-mm@kvack.org,
tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
ardb@kernel.org, dvhart@infradead.org, andy@infradead.org,
gregkh@linuxfoundation.org, rafael@kernel.org,
akpm@linux-foundation.org, daniel.gutson@eclypsium.com,
hughsient@gmail.com, alex.bazhaniuk@eclypsium.com,
alison.schofield@intel.com
Subject: Re: [PATCH v5 1/5] mm/memblock: Tag memblocks with crypto capabilities
Date: Fri, 14 Jan 2022 11:50:42 +0200 [thread overview]
Message-ID: <YeFHcrUUopm5xrtZ@kernel.org> (raw)
In-Reply-To: <20220113213027.457282-2-martin.fernandez@eclypsium.com>
On Thu, Jan 13, 2022 at 06:30:23PM -0300, Martin Fernandez wrote:
> Add the capability to mark regions of the memory memory_type able of
> hardware memory encryption.
>
> Also add the capability to query if all regions of a memory node are
> able to do hardware memory encryption to call it when initializing the
> nodes.
>
> Signed-off-by: Martin Fernandez <martin.fernandez@eclypsium.com>
> ---
> include/linux/memblock.h | 5 ++++
> mm/memblock.c | 49 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 54 insertions(+)
>
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 9dc7cb239d21..374c03e10b2e 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -41,6 +41,7 @@ extern unsigned long long max_possible_pfn;
> * via a driver, and never indicated in the firmware-provided memory map as
> * system RAM. This corresponds to IORESOURCE_SYSRAM_DRIVER_MANAGED in the
> * kernel resource tree.
> + * @MEMBLOCK_CRYPTO_CAPABLE: capable of hardware encryption
> */
> enum memblock_flags {
> MEMBLOCK_NONE = 0x0, /* No special request */
> @@ -48,6 +49,7 @@ enum memblock_flags {
> MEMBLOCK_MIRROR = 0x2, /* mirrored region */
> MEMBLOCK_NOMAP = 0x4, /* don't add to kernel direct mapping */
> MEMBLOCK_DRIVER_MANAGED = 0x8, /* always detected via a driver */
> + MEMBLOCK_CRYPTO_CAPABLE = 0x10, /* capable of hardware encryption */
Nit: please keep the comments aligned with TAB.
> };
>
> /**
> @@ -121,6 +123,9 @@ int memblock_physmem_add(phys_addr_t base, phys_addr_t size);
> void memblock_trim_memory(phys_addr_t align);
> bool memblock_overlaps_region(struct memblock_type *type,
> phys_addr_t base, phys_addr_t size);
> +bool memblock_node_is_crypto_capable(int nid);
> +int memblock_mark_crypto_capable(phys_addr_t base, phys_addr_t size);
> +int memblock_clear_crypto_capable(phys_addr_t base, phys_addr_t size);
> int memblock_mark_hotplug(phys_addr_t base, phys_addr_t size);
> int memblock_clear_hotplug(phys_addr_t base, phys_addr_t size);
> int memblock_mark_mirror(phys_addr_t base, phys_addr_t size);
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 1018e50566f3..61ec50647469 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -191,6 +191,27 @@ bool __init_memblock memblock_overlaps_region(struct memblock_type *type,
> return i < type->cnt;
> }
>
> +/**
> + * memblock_node_is_crypto_capable - get if whole node is capable
> + * of encryption
> + * @nid: number of node
> + *
> + * Iterate over all memory memblock_type and find if all regions under
> + * node @nid are capable of hardware encryption.
Please add Return: description, otherwise kernel-doc is unhappy
> + */
> +bool __init_memblock memblock_node_is_crypto_capable(int nid)
> +{
> + struct memblock_region *region;
> +
> + for_each_mem_region(region) {
> + if ((memblock_get_region_node(region) == nid) &&
> + !(region->flags & MEMBLOCK_CRYPTO_CAPABLE))
> + return false;
> + }
As we discussed on v3, please add a printk if the same node has both
crypto-capable and not crypto-capable regions.
https://lore.kernel.org/all/Ya++1FwWzKr2wYQH@kernel.org/
> +
> + return true;
> +}
> +
> /**
> * __memblock_find_range_bottom_up - find free area utility in bottom-up
> * @start: start of candidate range
> @@ -885,6 +906,34 @@ static int __init_memblock memblock_setclr_flag(phys_addr_t base,
> return 0;
> }
>
> +/**
> + * memblock_mark_crypto_capable - Mark memory regions capable of hardware
> + * encryption with flag MEMBLOCK_CRYPTO_CAPABLE.
> + * @base: the base phys addr of the region
> + * @size: the size of the region
> + *
> + * Return: 0 on success, -errno on failure.
> + */
> +int __init_memblock memblock_mark_crypto_capable(phys_addr_t base,
> + phys_addr_t size)
> +{
> + return memblock_setclr_flag(base, size, 1, MEMBLOCK_CRYPTO_CAPABLE);
> +}
> +
> +/**
> + * memblock_clear_crypto_capable - Clear flag MEMBLOCK_CRYPTO for a
> + * specified region.
> + * @base: the base phys addr of the region
> + * @size: the size of the region
> + *
> + * Return: 0 on success, -errno on failure.
> + */
> +int __init_memblock memblock_clear_crypto_capable(phys_addr_t base,
> + phys_addr_t size)
> +{
> + return memblock_setclr_flag(base, size, 0, MEMBLOCK_CRYPTO_CAPABLE);
> +}
> +
> /**
> * memblock_mark_hotplug - Mark hotpluggable memory with flag MEMBLOCK_HOTPLUG.
> * @base: the base phys addr of the region
> --
> 2.30.2
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2022-01-14 9:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-13 21:30 [PATCH v5 0/5] x86: Show in sysfs if a memory node is able to do encryption Martin Fernandez
2022-01-13 21:30 ` [PATCH v5 1/5] mm/memblock: Tag memblocks with crypto capabilities Martin Fernandez
2022-01-14 9:50 ` Mike Rapoport [this message]
2022-01-14 12:20 ` Martin Fernandez
2022-01-13 21:30 ` [PATCH v5 2/5] mm/mmzone: Tag pg_data_t " Martin Fernandez
2022-01-13 21:30 ` [PATCH v5 3/5] x86/e820: Tag e820_entry " Martin Fernandez
2022-01-14 18:17 ` Dave Hansen
2022-01-17 12:42 ` Martin Fernandez
2022-01-26 14:03 ` Martin Fernandez
2022-01-13 21:30 ` [PATCH v5 4/5] x86/efi: Tag e820_entries as crypto capable from EFI memmap Martin Fernandez
2022-01-13 21:30 ` [PATCH v5 5/5] drivers/node: Show in sysfs node's crypto capabilities Martin Fernandez
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=YeFHcrUUopm5xrtZ@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex.bazhaniuk@eclypsium.com \
--cc=alison.schofield@intel.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=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=martin.fernandez@eclypsium.com \
--cc=mingo@redhat.com \
--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.