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.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
