public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Babu Moger <babu.moger@amd.com>,
	corbet@lwn.net, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, hpa@zytor.com, pbonzini@redhat.com,
	sean.j.christopherson@intel.com, 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,
	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 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86
Date: Thu, 7 May 2020 07:44:44 -0700	[thread overview]
Message-ID: <034cfb90-7f75-8e36-5b1e-ceaef0dfa50d@intel.com> (raw)
In-Reply-To: <20200507072934.d5l6cpqyy54lrrla@linutronix.de>

On 5/7/20 12:29 AM, Sebastian Andrzej Siewior wrote:
>>> -config X86_INTEL_MEMORY_PROTECTION_KEYS
>>> -	prompt "Intel Memory Protection Keys"
>>> +config X86_MEMORY_PROTECTION_KEYS
>>> +	prompt "Memory Protection Keys"
>>>  	def_bool y
>>>  	# Note: only available in 64-bit mode
>>> -	depends on CPU_SUP_INTEL && X86_64
>>> +	depends on X86_64 && (CPU_SUP_INTEL || CPU_SUP_AMD)
>>>  	select ARCH_USES_HIGH_VMA_FLAGS
>>>  	select ARCH_HAS_PKEYS
>>>  	---help---
>> It's a bit of a bummer that we're going to prompt everybody doing
>> oldconfig's for this new option.  But, I don't know any way for Kconfig
>> to suppress it if the name is changed.  Also, I guess the def_bool=y
>> means that menuconfig and olddefconfig will tend to do the right thing.
> You could add a new option (X86_MEMORY_PROTECTION_KEYS) which is
> def_bool X86_INTEL_MEMORY_PROTECTION_KEYS and avoiding the prompt line.
> Soo it is selected based on the old option and the user isn't bother. A
> few cycles later you could remove intel option and add prompt to other.
> But still little work for…

That does sound viable, if we decide it's all worth it.

So, for now my preference would be to change the prompt, but leave the
CONFIG_ naming in place.  If we decide that transitioning the config is
the right thing (I don't feel super strongly either way), let's use
Sebastian's trick to avoid the Kconfig prompts.

  reply	other threads:[~2020-05-07 14:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-06 22:02 [PATCH 0/2] arch/x86: Enable MPK feature on AMD Babu Moger
2020-05-06 22:02 ` [PATCH 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 Babu Moger
2020-05-06 22:21   ` Dave Hansen
2020-05-06 22:28     ` Dave Hansen
2020-05-06 22:36     ` Logan Gunthorpe
2020-05-07  7:29     ` Sebastian Andrzej Siewior
2020-05-07 14:44       ` Dave Hansen [this message]
2020-05-07 15:16         ` Paolo Bonzini
2020-05-07 16:06           ` Babu Moger
2020-05-07 16:07             ` Paolo Bonzini
2020-05-07 16:11               ` Babu Moger
2020-05-06 22:02 ` [PATCH 2/2] KVM: SVM: Add support for MPK feature on AMD Babu Moger
2020-05-06 22:26   ` Sean Christopherson
2020-05-07  8:07     ` Paolo Bonzini
2020-05-06 22:36   ` Dave Hansen

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=034cfb90-7f75-8e36-5b1e-ceaef0dfa50d@intel.com \
    --to=dave.hansen@intel.com \
    --cc=aarcange@redhat.com \
    --cc=acme@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=anshuman.khandual@arm.com \
    --cc=arjunroy@google.com \
    --cc=asteinhauser@google.com \
    --cc=babu.moger@amd.com \
    --cc=bigeasy@linutronix.de \
    --cc=bp@alien8.de \
    --cc=changbin.du@intel.com \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=ira.weiny@intel.com \
    --cc=jan.kiszka@siemens.com \
    --cc=jgross@suse.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=justin.he@arm.com \
    --cc=keescook@chromium.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=luto@kernel.org \
    --cc=mchehab+samsung@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namit@vmware.com \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=peterz@infradead.org \
    --cc=robin.murphy@arm.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=sam@ravnborg.org \
    --cc=sean.j.christopherson@intel.com \
    --cc=steven.price@arm.com \
    --cc=tglx@linutronix.de \
    --cc=thellstrom@vmware.com \
    --cc=vineela.tummalapalli@intel.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    --cc=yamada.masahiro@socionext.com \
    --cc=yang.shi@linux.alibaba.com \
    /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