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

[Tom Lendacky]

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.
>