[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241025135527.GCZxujT_ffqa2fHoAa@fat_crate.local>
Date: Fri, 25 Oct 2024 15:55:27 +0200
From: Borislav Petkov <bp@...en8.de>
To: Tom Lendacky <thomas.lendacky@....com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Michael Roth <michael.roth@....com>,
Ashish Kalra <ashish.kalra@....com>,
Nikunj A Dadhania <nikunj@....com>,
Neeraj Upadhyay <Neeraj.Upadhyay@....com>
Subject: Re: [PATCH v4 1/8] x86/sev: Prepare for using the RMPREAD
instruction to access the RMP
On Fri, Oct 25, 2024 at 08:47:06AM -0500, Tom Lendacky wrote:
> Just wanted to show you what it looks like. There still is a lot of change
> because of the new argument and using a structure now instead of the
> direct entry.
Ah ok.
> I can change back and maybe add some more detail above the struct names if
> that suffices.
Yeah, I think "struct rmpread" is simply a strange thing to have when there is
an instruction of that name. I think the naming of the structs should aim at
being descriptive as to what they are. Hypothetical example:
struct rmpentry_as_found_in_the_rmptable ...
struct rmpentry_as_returned_by_rmpread
Now make the above shorter by keeping the information. :-)
IOW, on the one hand, "rmpentry_raw" or "rmpentry_direct" or
"rmpentry_<something>", and, OTOH, just "struct rmpentry" kinda makes sense
and it is short enough.
At least how I see it rn...
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists