Re: [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel in-place

From: Tom Lendacky
Date: Mon Jun 26 2017 - 12:35:34 EST


On 6/26/2017 10:45 AM, Borislav Petkov wrote:
On Fri, Jun 23, 2017 at 12:44:46PM -0500, Tom Lendacky wrote:
Normally the __p4d() macro would be used and that would be ok whether
CONFIG_X86_5LEVEL is defined or not. But since __p4d() is part of the
paravirt ops path I have to use native_make_p4d().

So __p4d is in !CONFIG_PARAVIRT path.

Regardless, we use the native_* variants in generic code to mean, not
paravirt. Just define it in a separate patch like the rest of the p4*
machinery and use it in your code. Sooner or later someone else will
need it.

Ok, will do.


True, 5-level will only be turned on for specific hardware which is why
I originally had this as only 4-level pagetables. But in a comment from
you back on the v5 version you said it needed to support 5-level. I
guess we should have discussed this more,

AFAIR, I said something along the lines of "what about 5-level page
tables?" and whether we care.

My bad, I took the meaning of that question the wrong way then.

Thanks,
Tom


but I also thought that should our hardware ever support 5-level
paging in the future then this would be good to go.

There it is :-)

The macros work great if you are not running identity mapped. You could
use p*d_offset() to move easily through the tables, but those functions
use __va() to generate table virtual addresses. I've seen where
boot/compressed/pagetable.c #defines __va() to work with identity mapped
pages but that would only work if I create a separate file just for this
function.

Given when this occurs it's very similar to what __startup_64() does in
regards to the IS_ENABLED(CONFIG_X86_5LEVEL) checks.

Ok.