Re: [PATCH] x86/mm: Split read_cr3() into read_cr3_pa() and __read_cr3()

From: Borislav Petkov <bp@alien8.de>
To: Andy Lutomirski <luto@kernel.org>
Cc: Juergen Gross <jgross@suse.com>,
	Tom Lendacky <thomas.lendacky@amd.com>, X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH] x86/mm: Split read_cr3() into read_cr3_pa() and __read_cr3()
Date: Tue, 13 Jun 2017 18:18:54 +0200	[thread overview]
Message-ID: <20170613161854.xnippoph2mysxpnz__39358.4086480134$1497370810$gmane$org@pd.tnic> (raw)
In-Reply-To: <CALCETrWnMYFdfvswHp01xYhj8KBfw1cVYvPuEOEjHcNUV+s_mw@mail.gmail.com>

On Tue, Jun 13, 2017 at 09:00:01AM -0700, Andy Lutomirski wrote:
> 1. Make sure that every read_cr3() instance got converted.  I didn't
> want a mid-air collision with someone else's patch in which it would
> appear to apply and compile but the result would randomly fail on PCID
> systems.

Right.

> 2. Make users realize that CR3 ain't what it used to be.  __read_cr3()
> means "return this complicated register value -- I know what I'm
> doing" and read_cr3_pa() means "give me the PA".

Agreed with the _pa thing.

> Maybe we could rename __read_cr3() to read_cr3_raw()?  If we really
> wanted lots of clarity, __read_cr4() could become read_cr4_noshadow(),
> I suppose.

Yeah, both make sense to me. I like the _raw thing and the _noshadow
too, as they actually say what the function *really* does.

In any case, the __ variant is less descriptive than having:

read_crX_pa
read_crX_raw
read_crX_noshadow

and so on which actually say what they each do and when you wonder which
to use, you know.

> What do you think?  My general preference is to clean this up after
> the rest of the big patchsets (SME and PCID) land.

Of course.

Thanks.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel