[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e96a653d-bd13-ed25-81e2-b7301d7f92f1@amd.com>
Date: Wed, 13 May 2020 10:56:42 -0500
From: Babu Moger <babu.moger@....com>
To: Dave Hansen <dave.hansen@...el.com>, corbet@....net,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, hpa@...or.com,
pbonzini@...hat.com, sean.j.christopherson@...el.com
Cc: 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 v4 1/3] arch/x86: Update config and kernel doc for MPK
feature on AMD
On 5/13/20 10:09 AM, Dave Hansen wrote:
> On 5/12/20 4:58 PM, Babu Moger wrote:
>> +config X86_MEMORY_PROTECTION_KEYS
>> + # Both Intel and AMD platforms support "Memory Protection Keys"
>> + # feature. So add a generic option X86_MEMORY_PROTECTION_KEYS
>> + # and set the option whenever X86_INTEL_MEMORY_PROTECTION_KEYS
>> + # is set. This is to avoid the confusion about the feature
>> + # availability on AMD platforms. Also renaming the old option
>> + # would cause the user an extra prompt during the kernel
>> + # configuration. So avoided changing the old config name.
>> + def_bool X86_INTEL_MEMORY_PROTECTION_KEYS
>
> Hi Babu,
>
> I made a request earlier for an end date (or version) to be included
> here. I believe that appeared in one of your earlier versions, but it
> was removed in later ones.
>
> Was there a reason for that?
Dave, Sorry, I misunderstood that. I thought we probably are not going to
change the sources/makefile(ifdefs mostly) as it was technically not
required. Now I am reading that we are going to change that in the future
and just keep X86_MEMORY_PROTECTION_KEYS going forward.
Sure. I will add the text you proposed. Please feel free to correct again.
>
> I'd really prefer to put some kind of expiration date on the config
> option. It will outlive us all otherwise.
>
>> Memory Protection Keys for Userspace (PKU aka PKEYs) is a feature
>> which is found on Intel's Skylake "Scalable Processor" Server CPUs.
>> -It will be avalable in future non-server parts.
>> +It will be available in future non-server parts. Also, AMD64
>> +Architecture Programmer’s Manual defines PKU feature in AMD processors.
>
> I actually worked pretty hard to make that sentence useful to Linux
> users. Instead of forcing them to imply that it will be available on
> future AMD CPUs, can we just come out and say it? Can we give any more
> information to our users?
>
> Naming the AMD manual in which the feature is defined doesn't really
> help our users. Let's not waste the bytes on it.
>
> How about:
>
> Memory Protection Keys for Userspace (PKU aka PKEYs) is a
> feature which is found on Intel's Skylake (and later) "Scalable
> Processor" Server CPUs. It will be avalable in future non-
> server Intel parts and future AMD parts.
This should be good enough. Thanks.
>
> Any clarity you can add, such as to say what AMD is doing for server vs.
> client would be nice.
>
> BTW, when I first submitted pkeys, I didn't have any statement like this
> in the changelog or documentation. Ingo, I think, asked for it and I
> worked with folks inside Intel to figure out how much we could say
> publicly about our plans. A similar effort from AMD would be much
> appreciated here.
>
Powered by blists - more mailing lists