[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e4a82789-4a2d-ec58-1d14-fc7a2f77d4d2@linux.intel.com>
Date: Wed, 22 Nov 2017 14:50:32 -0800
From: Dave Hansen <dave.hansen@...ux.intel.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
richard.fellner@...dent.tugraz.at, moritz.lipp@...k.tugraz.at,
daniel.gruss@...k.tugraz.at, michael.schwarz@...k.tugraz.at,
luto@...nel.org, torvalds@...ux-foundation.org,
keescook@...gle.com, hughd@...gle.com, x86@...nel.org
Subject: Re: [PATCH 08/30] x86, kaiser: unmap kernel from userspace page
tables (core patch)
On 11/20/2017 09:21 AM, Thomas Gleixner wrote:
>> +}
>> +
>> static inline void native_set_p4d(p4d_t *p4dp, p4d_t p4d)
>> {
>> +#if defined(CONFIG_KAISER) && !defined(CONFIG_X86_5LEVEL)
>> + /*
>> + * set_pgd() does not get called when we are running
>> + * CONFIG_X86_5LEVEL=y. So, just hack around it. We
>> + * know here that we have a p4d but that it is really at
>> + * the top level of the page tables; it is really just a
>> + * pgd.
>> + */
>> + /* Do we need to also populate the shadow p4d? */
>> + if (is_userspace_pgd(p4dp))
>> + native_get_shadow_p4d(p4dp)->pgd = p4d.pgd;
> native_get_shadow_p4d() is kinda confusing, as it suggest that we get the
> entry not the pointer to it. native_get_shadow_p4d_ptr() is what it
> actually wants to be, but a setter e.g. native_set_shadow...(), we also
> have set_pgd() would be more obvious I think.
How about "kernel_to_shadow_pgdp()"? ... and friends
Powered by blists - more mailing lists