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