On 6/8/2017 1:05 AM, Andy Lutomirski wrote:
On Wed, Jun 7, 2017 at 12:14 PM, Tom Lendacky <thomas.lendacky@xxxxxxx> wrote:
The cr3 register entry can contain the SME encryption bit that indicates
the PGD is encrypted. The encryption bit should not be used when creating
a virtual address for the PGD table.
Create a new function, read_cr3_pa(), that will extract the physical
address from the cr3 register. This function is then used where a virtual
address of the PGD needs to be created/used from the cr3 register.
This is going to conflict with:
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/pcid&id=555c81e5d01a62b629ec426a2f50d27e2127c1df
We're both encountering the fact that CR3 munges the page table PA
with some other stuff, and some readers want to see the actual CR3
value and other readers just want the PA. The thing I prefer about my
patch is that I get rid of read_cr3() entirely, forcing the patch to
update every single reader, making review and conflict resolution much
safer.
I'd be willing to send a patch tomorrow that just does the split into
__read_cr3() and read_cr3_pa() (I like your name better) and then we
can both base on top of it. Would that make sense?
That makes sense to me.
Also:
+static inline unsigned long read_cr3_pa(void)
+{
+ return (read_cr3() & PHYSICAL_PAGE_MASK);
+}
Is there any guarantee that the magic encryption bit is masked out in
PHYSICAL_PAGE_MASK? The docs make it sound like it could be any bit.
(But if it's one of the low 12 bits, that would be quite confusing.)
Right now it's bit 47 and we're steering away from any of the currently
reserved bits so we should be safe.
Thanks,
Tom
--Andy
