[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0c1bdd80-8e47-e65c-f421-0c5010058025@intel.com>
Date: Thu, 19 Jul 2018 07:19:01 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Kirill A. Shutemov" <kirill@...temov.name>
Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Tom Lendacky <thomas.lendacky@....com>,
Kai Huang <kai.huang@...ux.intel.com>,
Jacob Pan <jacob.jun.pan@...ux.intel.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCHv5 07/19] x86/mm: Mask out KeyID bits from page table entry
pfn
On 07/19/2018 02:54 AM, Kirill A. Shutemov wrote:
> On Wed, Jul 18, 2018 at 04:13:20PM -0700, Dave Hansen wrote:
>> On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
>>> + } else {
>>> + /*
>>> + * Reset __PHYSICAL_MASK.
>>> + * Maybe needed if there's inconsistent configuation
>>> + * between CPUs.
>>> + */
>>> + physical_mask = (1ULL << __PHYSICAL_MASK_SHIFT) - 1;
>>> + }
>> This seems like an appropriate place for a WARN_ON(). Either that, or
>> axe this code.
> There's pr_err_once() above in the function.
Do you mean for the (tme_activate != tme_activate_cpu0) check?
But that's about double-activating this feature. This check is about an
inconsistent configuration between two CPUs which seems totally different.
Could you explain?
Powered by blists - more mailing lists