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

[Tom Lendacky <thomas.lendacky@xxxxxxx>]

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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel