[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <23ee5cfa-22ec-a367-04f2-4bca8edcfa9e@intel.com>
Date: Tue, 26 May 2020 08:33:36 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Borislav Petkov <bp@...en8.de>, Babu Moger <babu.moger@....com>
Cc: corbet@....net, tglx@...utronix.de, mingo@...hat.com,
hpa@...or.com, pbonzini@...hat.com,
sean.j.christopherson@...el.com, x86@...nel.org,
vkuznets@...hat.com, wanpengli@...cent.com, jmattson@...gle.com,
joro@...tes.org, dave.hansen@...ux.intel.com, luto@...nel.org,
peterz@...radead.org, mchehab+samsung@...nel.org,
changbin.du@...el.com, namit@...are.com, bigeasy@...utronix.de,
yang.shi@...ux.alibaba.com, asteinhauser@...gle.com,
anshuman.khandual@....com, jan.kiszka@...mens.com,
akpm@...ux-foundation.org, steven.price@....com,
rppt@...ux.vnet.ibm.com, peterx@...hat.com,
dan.j.williams@...el.com, arjunroy@...gle.com, logang@...tatee.com,
thellstrom@...are.com, aarcange@...hat.com, justin.he@....com,
robin.murphy@....com, ira.weiny@...el.com, keescook@...omium.org,
jgross@...e.com, andrew.cooper3@...rix.com,
pawan.kumar.gupta@...ux.intel.com, fenghua.yu@...el.com,
vineela.tummalapalli@...el.com, yamada.masahiro@...ionext.com,
sam@...nborg.org, acme@...hat.com, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v5] arch/x86: Update config and kernel doc for MPK feature
on AMD
On 5/23/20 5:21 AM, Borislav Petkov wrote:
>> +config X86_MEMORY_PROTECTION_KEYS
>> + # Set the "INTEL_"-free option whenever the "INTEL_" one is set.
>> + # The "INTEL_" one should be removed and replaced by this option
>> + # after 5.10. This avoids exposing most 'oldconfig' users to this
>> + # churn.
>> + def_bool X86_INTEL_MEMORY_PROTECTION_KEYS
> I only picked up the discussion from the sidelines but why do we need
> this at all? If we don't want to have churn, then we can leave it be
> called X86_INTEL_MEMORY_PROTECTION_KEYS, not change the manpage and
> have this depend on CPU_SUP_AMD too so that people can select it on AMD
> machines, and get on with our lives.
>
> So what's up?
Thanks for pointing that out. I think this ended up mixing together the
two alternative, which doesn't make much sense.
Babu, let's just leave the config option _naming_ entirely in place.
The only change should be to the dependencies and the description text.
Powered by blists - more mailing lists