From: "Huang, Kai" <kai.huang@intel.com>
To: "Schofield, Alison" <alison.schofield@intel.com>
Cc: "dhowells@redhat.com" <dhowells@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"Nakajima, Jun" <jun.nakajima@intel.com>,
"Shutemov, Kirill" <kirill.shutemov@intel.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
"Sakkinen, Jarkko" <jarkko.sakkinen@intel.com>,
"jmorris@namei.org" <jmorris@namei.org>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: RE: [RFC 11/12] keys/mktme: Add a new key service type for memory encryption keys
Date: Mon, 17 Sep 2018 10:48:33 +0000 [thread overview]
Message-ID: <105F7BF4D0229846AF094488D65A098935432E09@PGSMSX112.gar.corp.intel.com> (raw)
In-Reply-To: <20180915000639.GA28666@alison-desk.jf.intel.com>
> -----Original Message-----
> From: Schofield, Alison
> Sent: Saturday, September 15, 2018 12:07 PM
> To: Huang, Kai <kai.huang@intel.com>
> Cc: dhowells@redhat.com; tglx@linutronix.de; Nakajima, Jun
> <jun.nakajima@intel.com>; Shutemov, Kirill <kirill.shutemov@intel.com>;
> Hansen, Dave <dave.hansen@intel.com>; Sakkinen, Jarkko
> <jarkko.sakkinen@intel.com>; jmorris@namei.org; keyrings@vger.kernel.org;
> linux-security-module@vger.kernel.org; mingo@redhat.com; hpa@zytor.com;
> x86@kernel.org; linux-mm@kvack.org
> Subject: Re: [RFC 11/12] keys/mktme: Add a new key service type for memory
> encryption keys
>
> On Sun, Sep 09, 2018 at 08:29:29PM -0700, Huang, Kai wrote:
> > > + */
> > > +static int mktme_build_cpumask(void) {
> > > + int online_cpu, mktme_cpu;
> > > + int online_pkgid, mktme_pkgid = -1;
> > > +
> > > + if (!zalloc_cpumask_var(&mktme_cpumask, GFP_KERNEL))
> > > + return -ENOMEM;
> > > +
> > > + for_each_online_cpu(online_cpu) {
> > > + online_pkgid = topology_physical_package_id(online_cpu);
> > > +
> > > + for_each_cpu(mktme_cpu, mktme_cpumask) {
> > > + mktme_pkgid =
> > > topology_physical_package_id(mktme_cpu);
> > > + if (mktme_pkgid == online_pkgid)
> > > + break;
> > > + }
> > > + if (mktme_pkgid != online_pkgid)
> > > + cpumask_set_cpu(online_cpu, mktme_cpumask);
> > > + }
> >
> > Could we use 'for_each_online_node', 'cpumask_first/next', etc to simplify the
> logic?
>
> Kai,
>
> I tried to simplify it and came up with code that looked like this:
>
> int lead_cpu, node;
> for_each_online_node(node) {
> lead_cpu = cpumask_first(cpumask_of_node(node));
> if (lead_cpu < nr_cpu_ids)
> cpumask_set_cpu(lead_cpu, mktme_cpumask_NEW);
> }
> When I test it on an SNC (Sub Numa Cluster) system it gives me too many CPU's.
> I get a CPU per Node (just like i asked for;) instead of per Socket.
> It has 2 sockets and 4 NUMA nodes.
>
> I kind of remember this when I originally coded it, hence the bottoms up
> approach using topology_physical_package_id()
>
> Any ideas?
Hmm.. I forgot the SNC case, sorry :(
So in case of SNC, is PCONFIG per-package, or per-node? I am not quite sure about this.
If PCONFIG is per-package, I don't have better idea than your original one. :)
Thanks,
-Kai
>
> Alison
>
next prev parent reply other threads:[~2018-09-17 10:48 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-07 22:23 [RFC 00/12] Multi-Key Total Memory Encryption API (MKTME) Alison Schofield
2018-09-07 22:34 ` [RFC 01/12] docs/x86: Document the Multi-Key Total Memory Encryption API Alison Schofield
2018-09-08 18:44 ` Randy Dunlap
2018-09-10 1:28 ` Huang, Kai
2018-09-11 0:13 ` Alison Schofield
2018-09-11 0:33 ` Huang, Kai
2018-09-11 0:45 ` Alison Schofield
2018-09-11 1:14 ` Huang, Kai
2018-09-11 0:14 ` Huang, Kai
2018-09-10 17:32 ` Sakkinen, Jarkko
2018-09-11 0:19 ` Alison Schofield
2018-09-07 22:34 ` [RFC 02/12] mm: Generalize the mprotect implementation to support extensions Alison Schofield
2018-09-10 10:12 ` Jarkko Sakkinen
2018-09-11 0:34 ` Alison Schofield
2018-09-07 22:34 ` [RFC 03/12] syscall/x86: Wire up a new system call for memory encryption keys Alison Schofield
2018-09-07 22:36 ` [RFC 04/12] x86/mm: Add helper functions to manage " Alison Schofield
2018-09-10 2:56 ` Huang, Kai
2018-09-10 23:37 ` Huang, Kai
2018-09-10 23:41 ` Alison Schofield
2018-09-10 17:37 ` Sakkinen, Jarkko
2018-09-07 22:36 ` [RFC 05/12] x86/mm: Add a helper function to set keyid bits in encrypted VMA's Alison Schofield
2018-09-10 17:57 ` Sakkinen, Jarkko
2018-09-07 22:36 ` [RFC 06/12] mm: Add the encrypt_mprotect() system call Alison Schofield
2018-09-10 18:02 ` Jarkko Sakkinen
2018-09-11 2:15 ` Alison Schofield
2018-09-07 22:37 ` [RFC 07/12] x86/mm: Add helper functions to track encrypted VMA's Alison Schofield
2018-09-10 3:17 ` Huang, Kai
2018-09-07 22:37 ` [RFC 08/12] mm: Track VMA's in use for each memory encryption keyid Alison Schofield
2018-09-10 18:20 ` Jarkko Sakkinen
2018-09-11 2:39 ` Alison Schofield
2018-09-07 22:37 ` [RFC 09/12] mm: Restrict memory encryption to anonymous VMA's Alison Schofield
2018-09-10 18:21 ` Sakkinen, Jarkko
2018-09-10 18:57 ` Dave Hansen
2018-09-10 21:07 ` Jarkko Sakkinen
2018-09-10 21:09 ` Dave Hansen
2018-09-07 22:38 ` [RFC 10/12] x86/pconfig: Program memory encryption keys on a system-wide basis Alison Schofield
2018-09-10 1:46 ` Huang, Kai
2018-09-10 18:24 ` Sakkinen, Jarkko
2018-09-11 2:46 ` Alison Schofield
2018-09-11 14:31 ` Jarkko Sakkinen
2018-09-07 22:38 ` [RFC 11/12] keys/mktme: Add a new key service type for memory encryption keys Alison Schofield
2018-09-10 3:29 ` Huang, Kai
2018-09-10 21:47 ` Alison Schofield
2018-09-15 0:06 ` Alison Schofield
2018-09-17 10:48 ` Huang, Kai [this message]
2018-09-17 22:34 ` Huang, Kai
2018-09-07 22:39 ` [RFC 12/12] keys/mktme: Do not revoke in use " Alison Schofield
2018-09-10 1:10 ` [RFC 00/12] Multi-Key Total Memory Encryption API (MKTME) Huang, Kai
2018-09-10 19:10 ` Alison Schofield
2018-09-11 3:15 ` Huang, Kai
2018-09-10 17:29 ` Sakkinen, Jarkko
2018-09-11 22:03 ` [RFC 11/12] keys/mktme: Add a new key service type for memory encryption keys David Howells
2018-09-11 22:39 ` Alison Schofield
2018-09-11 23:01 ` David Howells
2018-09-11 22:56 ` [RFC 04/12] x86/mm: Add helper functions to manage " David Howells
2018-09-12 11:12 ` [RFC 12/12] keys/mktme: Do not revoke in use " David Howells
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=105F7BF4D0229846AF094488D65A098935432E09@PGSMSX112.gar.corp.intel.com \
--to=kai.huang@intel.com \
--cc=alison.schofield@intel.com \
--cc=dave.hansen@intel.com \
--cc=dhowells@redhat.com \
--cc=hpa@zytor.com \
--cc=jarkko.sakkinen@intel.com \
--cc=jmorris@namei.org \
--cc=jun.nakajima@intel.com \
--cc=keyrings@vger.kernel.org \
--cc=kirill.shutemov@intel.com \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mingo@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox