Re: [PATCH v7 1/8] mm/memblock: Tag memblocks with crypto capabilities

[Daniel Gutson]

On Tue, Apr 26, 2022 at 10:21 AM Mike Rapoport <rppt@xxxxxxxxxx> wrote:
>
> On Tue, Apr 26, 2022 at 09:59:04AM -0300, Martin Fernandez wrote:
> > On 4/26/22, Mike Rapoport <rppt@xxxxxxxxxx> wrote:
> > > On Mon, Apr 25, 2022 at 02:15:19PM -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. Warn the user if a node has both encryptable and
> > >> non-encryptable regions.
> > >>
> > >> Signed-off-by: Martin Fernandez <martin.fernandez@xxxxxxxxxxxxx>
> > >> ---
> > >>  include/linux/memblock.h |  5 ++++
> > >>  mm/memblock.c            | 62 ++++++++++++++++++++++++++++++++++++++++
> > >>  2 files changed, 67 insertions(+)
> > >>
> > >> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > >> index 50ad19662a32..00c4f1a20335 100644
> > >> --- a/include/linux/memblock.h
> > >> +++ b/include/linux/memblock.h
> > >> @@ -40,6 +40,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 */
> > >> @@ -47,6 +48,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 */
> > >>  };
> > >>
> > >>  /**
> > >> @@ -120,6 +122,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 e4f03a6e8e56..fe62f81572e6 100644
> > >> --- a/mm/memblock.c
> > >> +++ b/mm/memblock.c
> > >> @@ -191,6 +191,40 @@ 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.
> > >> + *
> > >> + * Return:
> > >> + * true if every region in memory memblock_type is capable of
> > >
> > > I'd s/in memory memblock_type/in @nid
> > >
> >
> > Good, thanks.
> >
> > >> + * encryption, false otherwise.
> > >> + */
> > >> +bool __init_memblock memblock_node_is_crypto_capable(int nid)
> > >> +{
> > >> +  struct memblock_region *region;
> > >> +  int crypto_capables = 0;
> > >> +  int not_crypto_capables = 0;
> > >> +
> > >> +  for_each_mem_region(region) {
> > >> +          if (memblock_get_region_node(region) == nid) {
> > >> +                  if (region->flags & MEMBLOCK_CRYPTO_CAPABLE)
> > >> +                          crypto_capables++;
> > >> +                  else
> > >> +                          not_crypto_capables++;
> > >> +          }
> > >> +  }
> > >> +
> > >> +  if (crypto_capables > 0 && not_crypto_capables > 0)
> > >> +          pr_warn("Node %d has %d regions that are encryptable and %d regions
> > >> that aren't",
> > >> +                  nid, not_crypto_capables, crypto_capables);
> > >> +
> > >> +  return not_crypto_capables == 0;
> > >
> > > This will return true for memoryless nodes as well. Do you mean to consider
> > > them as capable of encryption?
> > >
> >
> > Not really, I didn't think about that to be honest. I don't think it's
> > a good idea to consider them as capable, right?
>
> I think capable of encryption would mean
>
>         crypto_capables && !not_crypto_capables

Since these operands were evaluated above with comparison ops, I would say
    crypto_capables > 0 && not_crypto_capables == 0
to improve readability and be explicit that they are numbers rather
than booleans.


>
> --
> Sincerely yours,
> Mike.