Re: [PATCH v3 1/3] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86

From: Babu Moger <babu.moger@amd.com>
To: Dave Hansen <dave.hansen@intel.com>,
	corbet@lwn.net, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, hpa@zytor.com, pbonzini@redhat.com,
	sean.j.christopherson@intel.com
Cc: x86@kernel.org, vkuznets@redhat.com, wanpengli@tencent.com,
	jmattson@google.com, joro@8bytes.org,
	dave.hansen@linux.intel.com, luto@kernel.org,
	peterz@infradead.org, mchehab+samsung@kernel.org,
	changbin.du@intel.com, namit@vmware.com, bigeasy@linutronix.de,
	yang.shi@linux.alibaba.com, asteinhauser@google.com,
	anshuman.khandual@arm.com, jan.kiszka@siemens.com,
	akpm@linux-foundation.org, steven.price@arm.com,
	rppt@linux.vnet.ibm.com, peterx@redhat.com,
	dan.j.williams@intel.com, arjunroy@google.com,
	logang@deltatee.com, thellstrom@vmware.com, aarcange@redhat.com,
	justin.he@arm.com, robin.murphy@arm.com, ira.weiny@intel.com,
	keescook@chromium.org, jgross@suse.com,
	andrew.cooper3@citrix.com, pawan.kumar.gupta@linux.intel.com,
	fenghua.yu@intel.com, vineela.tummalapalli@intel.com,
	yamada.masahiro@socionext.com, sam@ravnborg.org, acme@redhat.com,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org
Subject: Re: [PATCH v3 1/3] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86
Date: Tue, 12 May 2020 09:57:22 -0500	[thread overview]
Message-ID: <4984c0af-c20b-7084-9bca-5cb6bf385180@amd.com> (raw)
In-Reply-To: <a92f3247-4b1e-0ff2-c1c7-68c149c0142c@intel.com>

On 5/11/20 6:44 PM, Dave Hansen wrote:
> On 5/11/20 4:32 PM, Babu Moger wrote:
>> AMD's next generation of EPYC processors support the MPK (Memory
>> Protection Keys) feature.
>>
>> So, rename X86_INTEL_MEMORY_PROTECTION_KEYS to X86_MEMORY_PROTECTION_KEYS.
>>
>> No functional changes.
>>
>> AMD documentation for MPK feature is available at "AMD64 Architecture
>> Programmer’s Manual Volume 2: System Programming, Pub. 24593 Rev. 3.34,
>> Section 5.6.6 Memory Protection Keys (MPK) Bit". Documentation can be
>> obtained at the link below.

I will remove this text. This is not too relevant here.

> 
> I was hoping to see at least *some* justification in this changelog.  Do
> you think having "INTEL_" will confuse users?  Is there some technical
> merit to this change?
> 
> The naming churn is an obviously bad, not technically necessary change.

Yes. Technically not necessary. But can cause some confusion on non-intel
platforms.

> 
>> +config X86_MEMORY_PROTECTION_KEYS
>> +	# Note: This is an intermediate change to avoid config prompt to
>> +	# the users. Eventually, the option X86_INTEL_MEMORY_PROTECTION_KEYS
>> +	# should be changed to X86_MEMORY_PROTECTION_KEYS permanently after
>> +	# few kernel revisions.
>> +	def_bool X86_INTEL_MEMORY_PROTECTION_KEYS
> 
> "after a few kernel revisions" is code for "never". :)
> 
> Could we put an explicit date on this, please?  One year seems roughly
> right.  Or, maybe "after the v5.10" release, so that this will approach
> will make into at least one LTS kernel.
> 
> Maybe:
> 
> # 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.
> 
Yes, this should work.