[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240531125503.GEZlnIp7YobFu7g9iS@fat_crate.local>
Date: Fri, 31 May 2024 14:55:03 +0200
From: Borislav Petkov <bp@...en8.de>
To: Tom Lendacky <thomas.lendacky@....com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
linux-coco@...ts.linux.dev, svsm-devel@...onut-svsm.dev,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Dan Williams <dan.j.williams@...el.com>,
Michael Roth <michael.roth@....com>,
Ashish Kalra <ashish.kalra@....com>
Subject: Re: [PATCH v4 10/15] virt: sev-guest: Choose the VMPCK key based on
executing VMPL
On Wed, Apr 24, 2024 at 10:58:06AM -0500, Tom Lendacky wrote:
> +int snp_get_vmpl(void)
> +{
> + return vmpl;
The vmpl doesn't change after init, right?
If so, you can make that vmpl variable __ro_after_init and drop yet
another parrotting accessor.
> -static u32 vmpck_id;
> -module_param(vmpck_id, uint, 0444);
> +static int vmpck_id = -1;
> +module_param(vmpck_id, int, 0444);
> MODULE_PARM_DESC(vmpck_id, "The VMPCK ID to use when communicating with the PSP.");
Can the driver figure out the vmpck_id from the kernel directly instead
of having to supply it with a module param?
This is yet another silly module param which you have to go and engineer
into the loading and have to know what you're doing.
If you can automate that, then it is a win-win thing.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists